@Senor and I are excited to announce a potential new feature that we have dubbed “Posted Phonons”. We hope to get community feedback and involvement with the end goal being that posted phonons become part of the Phonon Protocol.
In short, a phonon is a private key that is guaranteed to be known by a single phonon card and no other entity. We will refer to this as the “phonon guarantee”. Currently, when transfering a phonon, both the sender and recipient must have their cards actively paired. This pairing process ensures both cards are following the protocol’s rules, thus maintaining the phonon guarantee.
This pairing process works extremely well in some situations but not so well in many others. For example, imagine your friend messages you saying that they have purchased tickets to a gig you wanted to see. You wish to reimburse them immediately using the Phonon protocol, but doing so would require you both to coordinate opening your Phonon wallet apps, unlocking your cards, and waiting for the transaction to complete. As a result, your friend instead tells you they are too busy to sync and to just Venmo them.
Another scenario where active pairing is an inconvenience is high traffic online retailers. For each customer paying with the Phonon protocol, the retailer would need to maintain an active pairing connection and potentially need a phonon card for each connection. Even if the retailer wanted to go down this route, the development work involved would be substantial and require knowledge outside your typical web developer’s skill set.
The changes we propose under posted phonons will drastically improve the usability of the Phonon protocol in the above scenarios, and many others, while maintaining the phonon guarantee.
We introduce the concept of a “posted phonon”, which is a phonon that exists outside of any phonon card. A posted phonon consists primarily of a phonon private key encrypted with the intended recipient’s card’s public key, a signature proving the posted phonon comes from a valid phonon card, and a nonce. If a posted phonon comes from a valid card and the private key can only be decrypted once by a single phonon card then the phonon guarantee is maintained.
To create a posted phonon the sender’s card requires the recipient’s card’s public key and nonce (more below on how these could be requested if a card is offline). Once created, the original phonon is removed from the sender’s card, and the sender receives a posted phonon which can then be sent to the recipient over any medium (HTTP, email, smoke signals). A recipient can consume any received posted phonons at any time but posted phonons should be consumed in order of ascending nonce (consecutive order is not required). A phonon card will reject any posted phonons containing a nonce less than its current internal nonce.
With posted phonons in place, the “reimbursing a friend for tickets” scenario looks a little different. Instead of having to coordinate being online to pair, you ask your friend for their card’s public key and a nonce. Once you receive these details you are able to generate a posted phonon and send it to them using whatever medium suits. Your friend can then consume the posted phonon onto their phonon card whenever it is convenient for them.
Although this flow reduces the need for you and your friend to coordinate being online at the same time, it does introduce friction in other areas. Your friend, the receiver, has to send you their public key and a suitable nonce. To provide a suitable nonce they must keep track of nonces they have previously given out. Additionally, the receiver must ensure that they consume posted phonons in the correct order. Imagine if your friend had previously provided their mother with a nonce lower than yours but had not yet received a posted phonon from her. In this scenario, if they were to receive your posted phonon before their mother’s, your friend can not consume your phonon until they either receive and consume their mothers, or confirm that their mother isn’t going to send a posted phonon with that lower nonce. If their mother’s posted phonon is received after yours is consumed the funds will be lost to both your friend and their mother forever.
To overcome these significant usability issues we have designed a service that we have dubbed a “phonon inbox”. A phonon inbox, sitting outside the of Phonon Protocol, is a service that manages the issuance, storage and consumption of posted phonons. To explain a phonon inbox we will again use the well-explored “reimbursing a friend for tickets” scenario.
Your friend, the recipient, at a previous point in time has signed up for a phonon inbox. When they signed up they provided the inbox with their desired username and their phonon card’s public key and current nonce. When you go to reimburse your friend, you enter their username into your phonon app which makes a request to your friend’s phonon inbox asking for their card’s public key and a nonce. Once these details are received your app immediately creates a posted phonon and sends it to your friend’s phonon inbox. Next time your friend opens their phonon app their card automatically consumes any ready posted phonons. To overcome the uncertainty around if it is safe to consume a received posted phonon when a posted phonon has not been received for a lower nonce, each nonce should be issued with an expiry timestamp. This timestamp gives the sender an explicit cutoff time in which they must send the posted phonon or it may be no longer consumable due the recipient possibly already consuming a posted phonon with a higher nonce.
Phonon inboxes can be self hosted or accessed through a service provider and therefore a discovery system is needed. One idea we have come up with is a “phonon inbox address”, such as hinchy$phonon.dao or personal$hinchy.com, which leverage the DNS system. Another complementary solution is for users to add their phonon inbox url to their ENS records.
- Implemented posted phonon functionality in phonon client’s mock card. You can view the code at Posted Phonons - Mock Card by ahinchliff · Pull Request #8 · ahinchliff/phonon-client · GitHub
- Implemented a phonon inbox proof of concept and a simple UI for sending and receiving posted phonons. Checkout https://posted.hinchliff.dev
- Some technical specs can be read at phonon-diagrams/posted-phonon-transfer-packet-schema.md at main · ahinchliff/phonon-diagrams · GitHub
- Get community consensus that this is a feature worth committing DAO resources towards
- Have the Core Devs confirm the feature is viable
- Complete the mock card implementation
- Have the Core Devs sign off on the mock card implementation
- Have the Core Devs implement the feature
- Phonon DAO develops an inbox system for public use