regarding #2: Pkarr is like DNS it in itself doesn't store data.

but users can point their Pkarr to where their hosting providers are. We also propose a specific API for and HTTP server not too different from WebDav to enable writing arbitrary files in users data stores. So typically a user will sign up to a homeserver, just like they sign up to Google drive for example, and point their pkarr to it. If the hosting provider is misbehaving, the user can point to another hosting provider since they have control over the keys.

Regarding #1 the demo app sends the signed packet to a relay that relays it to a large network of distributed hash table DHT. the only reason you send it to the relay, is because browsers don't support UDP, if you are using native app, that relay is not needed. But even in browser it is still better than Nostr relays, because all pkarr relays are equal, even if you run your own unknown pkarr relay, people will still find your data, because you all eventually publish the data to and query it from the DHT which is what is common and connect everyone, no need for both of us to write and read from common Nostr relays, so Pkarr relays are not cause for centralisation at all, they just support browsers temporarily until they eventually support Pkarr.

as for #3, the format is DNS packet encoding, we didn't reinvent this wheel, it is a very good encoding and very apt for this use case and allows us to leverage all DNS semantics and existing parsers in any language.