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).
This is relevant as we consider what sort of content moderation capabilities do we want baked into the protocol and how we want that to work. I’d suggest people consider what’s been tried elsewhere and what new things are being attempted as well (such as at ActivityPub protocol and ATProto used by Bluesky). While the intent of this protocol is not meant as a generic social media platform, content moderation is something that all social content protocols should consider and make design choices around. Even if that is as simple as “we’re explicit in choosing not to support content moderation at the protocol layer for X, Y, and Z reason”.
So I was just thinking about our discussion about content moderation and I think I might have an idea of how to do this based on the Horton protocol presented in the discussion from the ActivityPub Conf.
What if we added a query parameter to the V1 protocol that can be optionally used to point to a private IPFS network where the content has been published rather than the public one? The advantage here is that it allows us to use the concept of a “network of consent” from that talk as an access control mechanism rather than a global badbits list.
Essentially, if the query parameter is included, it’s a pointer to which network should be checked for the CID. If it’s not, the recipient should presume that the network in use is the global IPFS network. In this way, content availability becomes a method of access control in and of itself that allows for content moderation to simply based on where the content is pinned. However, since the content is easily identifiable on any network based on the hash of the content itself, it maintains parity across networks.
Then, we have 3 primary forms of content filtering here as primitives that I believe are all the primitives we would need in order to establish the emergent concept of “networks of consent” which Mastadon has looked towards.
The identifier of the sender based on the person who sent the transaction. I’m making an assumption here that this sender info is available now, which I wasn’t previously making so that needs to be changed.
The network where the content is pinned. This may be the global IPFS network (e.g. what everyone is used to accessing), which can be globally moderated but it may also be a private IPFS network. In which case, a sender publishing to a private network and then sending the private network gateway via the query parameter is an “introduction” which can be undone by the gateway at a network access level.
Badbits lists that are propogated by participants of the network or enforced by nodes/gateways of the network (or set by default by wallets for compliance purposes which users can opt out of using)
The value in this approach is that we’re establishing communal subgraphs that can be connected together easily using the specific network the content is published to. For example, this may be a private network established specifically between just the sender recipients or it may be a federated network for a group. The group can be easily recognized as trusted or not based on the private network too. In this way, what we’re doing is making it so that the common spaces that are easily accessed are moderated by design say via bad bits list or the identifier of the sender. However, since the networks themselves are a composable primitive, it becomes a way that users can that a sender propagate globally censored content that is locally still acceptable.
This would allow for this all to be done within the URI scheme itself, if my idea holds and only needs further definition of an additional query parameter to allow this pattern. I still want to sit and ponder on this idea a bit more before I modify the spec, but I think it’s something worth considering for others as a way to handle the tradeoffs between content moderation and robust decentralization. In particular, what I’m not certain about is what the correct exposure of this is within the UI and where the enforcement mechanisms should occur. However, instinctually, this feels like a good path worth exploring as a baseline primitive of V1.
To give context to the forum readers here, this came from presentations and conversations between Brave, the ECC team and community participants at the Z|ECC Summit today.
The question of moderation came out of conversations on how we ought to think about issues and risks related to the ability to store and distribute payloads that might include undesirable content, using the Zcash protocol as a transport mechanism. This capability will be unlocked when Brave completes its work to allow attachments, via IPFS, in the memo field of a shielded Zcash transaction.
