I’m hoping to get some community feedback on this and further review to see what people have in mind and what improvements can be made. Some key design decisions that I think are worth highlighting for why this is 2 separate ZIPs are:
Separating versions can make it difficult to maintain interoperability but also is necessary for cryptographic agility
The initial considerations around cryptography were heavily focused on simplification since it’s a required supported version. Therefore, compliant implementations would in theory always have one way to interoperably communicate without require lots of heavy lifting for implementors to support
Taking the simple for V1 approach also means that the V1 implementation could in theory be used as a bootstrapping protocol for a more complex V2/3/4/etc protocol being implemented such as setting up groups MLS protocol if it couldn’t all fit within the memo field as well to invite new members to the group.
IPFS was chosen as a starting storage layer for maximum decentralization of the messaging protocol, but I was intentional about making storage another extension layer by requiring the details of it be declared in the version. This does have the drawback that a version couples cryptographic implementation details to storage implementation details, but it reduces the combinatorial problem I’ve seen ran into previously in standards from too much extensibility. I’d be curious if others think this is the right tradeoff or if there’s changes people would like to see.
There’s probably a few more I’m forgetting to mention, but more than anything I’m just looking for feedback and opinions of whether this is a good direction, suggestions about key functionality that might be required, etc. Looking forward to hearing what people have in mind
BTW, I have started using the term “cryptographic alacrity”, coined by Soatok, for the approach to changing cryptographic algorithms that uses versioning rather than negotiation.
Good to see the delineation in terms. I always remembered it as the JWT vs Pareto token approach and in this case wanted to lean more towards the alacrity approach for sure after seeing lots of the downsides that popped up when I’ve worked on previous standards.
As for the concept, I’m definitely aligned, although I’m not certain about what the best approach for upgrading is. One thing I’ve seen from analyzing other protocols like TLS/email/XMPP is that ossification occurs and some people never upgrade. I’d be curious what sort of forced upgrading approach we might want to take for this, so definitely open to ideas.
In my mind, I originally had thought of this as a V1 is required every other subsequent version is optional, but maybe we have something like base protocol is force upgrade and then minor tweaks are optional extensions? I’m not too sure how that would play out or if there are better ideas, so definitely open to suggestions on this as others read through
On the surface, what would be your thoughts on your work towards blockchain growth? Recently, the blockchain grew quick and created some sync issues would this be an issue in your mind? Thanks
On the surface, what would be your thoughts on your work towards blockchain growth? Recently, the blockchain grew quick and created some sync issues would this be an issue in your mind?
With the version one, it could lead to more transaction growth. I think the ideal scenario here though is to not force all communications to occur through the actual chain itself. Instead, I’d expect it to be used as a means to setting up a separate E2EE channel of communication and the purpose in using memos then would be to address the trust on first use problem that occurs with other E2EE protocols. Right now there’s tradeoffs in requiring all messages to be stored on IPFS and sent via the chain. The first is that by putting all messages on chain, we’re expecting a pay per message fee which isn’t ideal. However, what we get in exchange for this is the decentralization properties of the chain and IPFS. Additionally, we run into IPFS pinning issues where a sender could theoretically pin the message themselves, but it presumes the user is running their own IPFS node which isn’t as common. So, they likely also need to pay to make sure the recipient will get the message given no one is incentivized to re-pin an encrypted message they can’t do anything with. Otherwise, the recipient will go to pickup the message and it won’t be available.
So, while there are tradeoffs here (one of which is increased usage of the chain) my expectation was that this would be iterated and improved on in future versions. However, in order to keep things simple to start it wasn’t ideal to go for that right away for both reasons of getting wallets implementing it plus having a solution that’s maximally decentralized and interoperable as the fallback option.
This idea was discussed in the past, (memos to support larger formats of data). Recently, when thinking about it; I keep thinking, will it be possible to have the larger formats of data in shielded assets? Or could an extended memo act more as a direct zec asset, the content in the memo makes the address an wallet.dat valuable/tradable?
If we start using big data formats in the blockchain itself, it will naturally complicate life for everyone, from node holders and wallet creators to ordinary users who will refuse to use Zcash. This proposal offers a compromise. Big data is stored in a decentralized securely encrypted cloud, access to which (a unique private key) is generated at the moment of sending. This cloud itself is not only encrypted, but also defragmented between storage participants. This way no one but the sender or receiver can access the data, but the blockchain remains as lightweight as possible. No one needs to scan and store unnecessary traffic intended only for the immediate participants in the correspondence. And who will store this data? Obviously the participants of the Filecoin project or something like that. The incentives of this vault are beyond the scope of zcash issues.
It could be a unique tool that even government security services don’t have. It seems like a serious Web 3.0 solution to me.
I’m not following this line of thinking, but I venture to guess you might be able to write a version spec that would allow for this since the generic URI structure is extensible enough to point to any off chain resource that’s encrypted.
If we start using big data formats in the blockchain itself, it will naturally complicate life for everyone, from node holders and wallet creators to ordinary users who will refuse to use Zcash. This proposal offers a compromise. Big data is stored in a decentralized securely encrypted cloud, access to which (a unique private key) is generated at the moment of sending.
This is precisely the motivation behind this. Every piece of data doesn’t need to be on chain. Especially if it’s not expected to be publicly available.
And who will store this data? Obviously the participants of the Filecoin project or something like that.
So this model of encrypted data doesn’t quite align with the replication model of IPFS which typically relies on nodes pinning content because they want to see it again. In this case, we’re using it as a inbox almost so that it can be picked up by the recipient and then dropped. So, more than likely messages that are encrypted are highly unlikely to be stored unless someone pays a node for it or self hosts it (which has it’s own privacy tradeoffs because then the recipient can get your IP address unless proxied via gateways).
