Looked into this, appears to use BEP0044, which is great, all Pkarr is, is using BEP0044 and choosing encoded DNS packets as the payload.

If this chooses to use DNS packets to encode whatever information it wants, using HTTPS or TXT or whatever relevant record type, then this is too is Pkarr since apkarr is just a subset of BEP0044.

I hope this puts as many ed25519 keys in people's hand as possible 

nostr:note19e0j2vc95uwzlvg2e9uw2xs4s4tnmx8xyee6e57lhjetdfxn24ss6vfh44 

 As long as both encode in the exact same way so that one can decide the other, it should be fine.  

 and we went with DNS packet encoding, we don't invent wheels that are already good enough and proven and simple.

if someone wants to use a different encoding, I honestly think they are the ones deliberately breaking compatibility. (of course the information in records can still require more interoperability and conventions). 

 By DNS packet encoding, do you mean RFC 1101? Or something else? 

 At least 1035 ... but most implementations support more, we use this library so we support these rfcs https://github.com/balliegojr/simple-dns/blob/main/simple-dns/README.md#dns-packet-parserbuilder

Pubky specifically cares about SVCB and HTTPs  records in in RFC 9460 

but the thing is, unsupported dns records are still parsed by anything that supports 1035... just not usefully.  

 well I omitted one small detail, Pkarr does NOT use a Salt.

Everything anyone needs to be compatible with pkarr is in this one document 

https://github.com/pubky/pkarr/blob/main/design/base.md