Open-Sourcing AVM Email: Joining Encrypted Communications with Defi: 3524536010

Governance Discussions xGov Proposals
21

I would like to start by thanking you for the comments and asking that my responses be interpreted in the least hostile way possible. My goal here is simply to clarify a few points and respond based on aspects I may not have fully understood from the arguments presented.

Regarding the adjustment in the proposal value: it was made both based on analyzing other projects and on the need to restructure our own scope. Unlike some of the examples mentioned, our project involves not only smart contracts but also a responsive frontend, which significantly increases both complexity and effort.

Initially, when we presented a broader proposal (including Algofun, Gainify, and AVM Email), there was an intention to make the overall package more cost-effective. However, we agreed with the feedback that the scope was too broad and not well defined. As a result, we decided to focus on the main product (AVM Email), better define the scope, and also add a testing layer covering all operations. With this change, the implicit ā€œbundle discountā€ no longer applies, which directly impacts the final cost.Regarding the concerns about the increased ask, I believe many of the arguments presented have been somewhat superficial. We all know that pricing a software product is complex and subjective. So far, only uhudo has provided a more structured argument explaining their perspective. While I donā€™t fully agree with the comparison made, I do appreciate the effort to provide a clear rationale.

For example, a random number generator library supporting four languages was mentioned. However, this is more about variations/dialects within ecosystems like Python and TypeScript, rather than four entirely distinct languages. Additionally, comparing a library/feature with a complete product (SaaS + smart contracts + interface) does not seem equivalent.

Another important point is that the impact of a library supporting multiple languages is very different from that of a SaaS product. Adoption for a library may increase with additional language support, but this does not apply in the same way to a product. For example, it is unlikely that someone would stop using a SaaS simply because it was built with Vue instead of React.

I would like to reiterate the point: if you believe the requested amount is too high, please explain it with a clear basis (if possible), ideally using proposals that are more comparable to ours.

22

Although I know the proposal is near a polling phase and I was not expecting a comment from Allan, I consistently check on this thread. I would humbly ask to hear out Allanā€™s thoughts here, as he does have some reasonable points. The most impactful of them I feel is that building the front-end on his and Ulrikā€™s side was no easy feat eitherā€” a reminder of the complexity we faced in putting AVM Email together, and the original ā€œbundledā€ proposal we had for the 3 separate platforms.

There were a lot of intricacies in balancing the different kinds of accounts and content history, as well as encrypting/decrypting contentā€”not only from a smart contract perspective (7 contracts specifically, as we mention) but also from a front-end perspective. Rendering everything, from the interfaces for preparing and sending emails to the option of crawling through email history with the least user friction possible, was incredibly tedious.

We essentially built and delivered a fully decentralized and end-to-end encrypted emailing platform on Algorand, we had no example implementations to build off of and had significant blockers along the way as the entire blockchain itself does not traditionally support encryption foundationally.

We threw in a commission system, tokenomics, and ā€œprivateā€ (server-gated) staking pools on top of that just to spice things up. There are very few developers exploring this category of work, even fewer that are not AF employees, either implementing or standardizing these encryption methods. As far as I know we are the first to fully build out something like this that is not just conceptual.

As always we are grateful for everyoneā€™s contributions in reviewing our proposal.

23

ā€œif you believe the requested amount is too high, please explain it with a clear basis (if possible)ā€

Simple. No one uses itā€¦

24

You guys keep asking for funding through pity and its sad.

ā€œThis was really hardā€ ā€œIt took a lot of timeā€

I always find it crazy how disconnected old school devs are from the actual world and their understanding for how people interpret thingsā€¦

25

We have lowered the ask to 150,000 as per discussions:

Open-Sourcing AVM Email: Fully Decentralized, Encrypted Communications & Defi | xGov

26

I want to share my thoughts on the crpyto involved here.

My main concern with basically anything that stores encrypted information on-chain is forward secrecy. This is especially true for a protocol that is only using ECC cryptography. All of this private data will eventually become exposed in a PQ world.

To help with forward secrecy, modern messaging apps typically use key ratcheting. The most popular implementation is Signalā€™s double ratchet. Thereā€™s also the more recent MLS, which is an attempt to standardize a scalable ratcheting protocol for group messaging.

Even if you were to adopt PQ signatures you still are susceptible to key leaks and losing all forward secrecy. You could implement ratcheting, but it scalability becomes even worse with PQ schemes.

With this context, my main questions would be ā€œwho are the users and are they okay with this weakened security model?ā€ The term ā€œweakenedā€ is relative to off-chain messaging apps that preserve forward secrecy. This also begs the question of whether or not the users are even fully aware of the security model.

I think the main problem that is trying to be solved here is ā€œI know this persons Algorand address and I want to communicate with them in private.ā€ If that is the case, then I think this can be solved by having a one-time communication on-chain to establish an off-chain communication channel (for example, sharing a signal handle). The value of storing each message publicly and indefinitely (by archival nodes) is not clear to me, thus Iā€™m not convinced the weaker security is justifiable.

27

Yes but then the app is no longer decentralized, because off-chain communications are now, although still encrypted, stored off-chain by some entity.

I have never been a fan of centralized services, especially with data encrypted or not, because access to that data is at the discretion of the host.

Just as a note we have never advertised as being PQ-proof, but I understand the PQ concerns as this is a popular topic on Algorand.

I believe the forward-secrecy is a trade-off to ephemeral keys I know we discussed at one-point in time. But we decided on a route where history can be accessed at any time by the two users communicating. Again this can be facilitated off chain but goes back to my centralization concern.

Additionally, I would be interested in hearing your thoughts on the SEALs implementation, which is what I was signaling in the discord, although of course I appreciate your feedback here as well! And weā€™d be happy to iterate in the future ā€” although I believe this feedback requires pulling a lot of features.

Late Edit: If there was a genuine interest we would be happy to explore a shift in the usecase implementation after this proposal. But it would be nice to have some assurance that this is desired, we were also discussing going mobile the other day, but it would be nice to have a discussion about the exact implementation and plan appropriately if DevRel would be willing to provide some guidance. But I will add that Iā€™m not a fan of a sort of registry mapping to a signal handle, it feels like low-hanging fruit.

28

Yes but then the app is no longer decentralized, because off-chain communications are now, although still encrypted, stored off-chain by some entity.

I have never been a fan of centralized services, especially with data encrypted or not, because access to that data is at the discretion of the host.

Iā€™m curious about how you feel about how AVM Email is positioned against something like Matrix, where you donā€™t need to rely on a third party and have E2EE with key ratcheting via Olm. As an end-user itā€™s not clear what using AVM Email gives me over setting up my own Matrix server. With Matrix I donā€™t have to worry about all my messages being public. In both cases I need to setup infrastructure to avoid reliance on third parties.

To be clear, Iā€™m not saying there definitely isnā€™t value here, but Iā€™m saying that value of the product isnā€™t really clear to me based on the proposal and README. Maybe Iā€™m wrong and users donā€™t really care about security that much, but I think the users that would care about decentralization would also care about security.

Just as a note we have never advertised as being PQ-proof, but I understand the PQ concerns as this is a popular topic on Algorand.

Yeah thatā€™s fair but itā€™s kinda what Iā€™m getting at. Not being PQ-secure right now has a LOT of implications because this data is on a public blockchain. If the messages werenā€™t on chain current-day PQ security would not be as important. Every single message for AVM Email will be indefinitely accessible by every single malicious PQ actor. This is something that I think should be clearly communicated to the users.

Again I donā€™t think this invalidates all the hard work done here. For some use cases where you donā€™t need forward secrecy (for example making a private offer on an asset in someones account) I think this makes sense. What gives me pause is the fact that this proposed as a general purpose private message solution where all the security nuances are not mentioned. Perhaps something more targeted for specific use cases where the security model was more narrow would be less concerning to me.

Additionally, I would be interested in hearing your thoughts on the SEALs implementation, which is what I was signaling in the discord, although of course I appreciate your feedback here as well! And weā€™d be happy to iterate in the future ā€” although I believe this feedback requires pulling a lot of features.

I like some of the cypto decisions they made. Particularly using HPKE. HPKE is nice because it gives flexibility for the underlying KEM. For example, you could have a protocol that uses X25519 today but then switch to X-Wing (or whatever the finalized version is named) for PQ security. You just need to ensure the Algorithm ID (as per RFC 9180 Section 7) is included with messages, then clients can handle the messages with a standard HPKE library. It also fits in nice with MLS, which is compitble with PQ schemes but itā€™s just very hard to scale.

The trade-off with your approach is that you can derive keys from signatures, which gives compatibility with things like ledger or KMS that may not natively support DH. This is definitely a strong selling point from an Algorand userā€™s POV.

Otherwise I have basically the same concerns for SEAL as I outlined here, with the additional concerns over the practically of scaling PQ schemes on-chain.

29

No worries! Iā€™m grateful we had someone of your caliber and experience provide us feedback =)

I think the general friction of set-up alone would be enough, not accounting for the fact that even I did not have this on my radar until you mentioned it.

indefinitely accessible by every single malicious PQ actor. This is something that I think should be clearly communicated to the users.

I mean, theoretically every platform should have a disclaimer that they are not PQ proof (99% of all platforms even outside of Algorand and blockchain itself), itā€™s just not a smart marketing move ā€” but for our usecase it should be disclosed ā€” thatā€™s fair, and Iā€™ll pass this over to @Allan to add, I appreciate you bringing this to our attention.

30

I think the general friction of set-up alone would be enough, not accounting for the fact that even I did not have this on my radar until you mentioned it.

Yeah thatā€™s fair, I imagine nodekit/FUNC make it a lot easier to setup an Algorand node versus a matrix server.

Matrix is pretty cool! Itā€™s a decentralized chat protocol with federation so anyone can setup a server and talk to anyone else on another server. Itā€™s basically becoming the replacement for IRC. Many FOSS projects are using it for their primary chat channel. Mozilla, Fedora, KDE, GNOME, neovim, etc.

I mean, theoretically every platform should have a disclaimer that they are not PQ proof (99% of all platforms even outside of Algorand and blockchain itself), itā€™s just not a smart marketing move ā€” but for our usecase it should be disclosed ā€” thatā€™s fair, and Iā€™ll pass this over to @Allan to add, I appreciate you bringing this to our attention.

Yeah I appreciate thereā€™s a lot of nuance here and itā€™s not an easy thing to communicate. I think the main difference is that you are marketing as a privacy solution but being on a public blockchain has massive privacy implications. Also worth mentioning Signal has used PQXDH to prevent harvest now; decrypt later quantum attacks since 2023 and Matrix (and Google RCS) has been working on MLS integration https://arewemlsyet.com/ (which is not directly PQ, but its a good step towards PQ)

31

Absolutely.

Question: Would it be appropriate to spin a Matrix up on otherā€™s behalf somehow ā€” like autonomously as an integration? Eg; Per 2+ users

Also Allan will comment shortly with a snippet of the new PQ disclaimer in FAQ

32

I have a background in Computer Science, though I admit that the topic of quantum cryptography extends somewhat beyond my area of expertise. I added an FAQ and looked into references from some articles that I considered relevant both to inform and to provide context that, although post-quantum computing represents a potential threat, it is not yet imminent in the current landscape. I understand that the ideal scenario would be the absence of this risk entirely and the assurance that such data could never be decrypted in the future.

image
image795Ɨ510 40.5 KB

33

Letā€™s add it to the ā€œFrequently Asked Questionsā€ section on the website as well as the Repo you showed here @Allan

34

The ideal solution is you just let users choose whichever server they want to use. You could make a server for them and create their account (and have them change their password), but I think it makes much more sense to just let both users decide which server they want to use (could be their own, could be a popular one like matrix, could be one you setup, etc.).

The main problem is that it doesnā€™t really matter if its imminent. There is simply no way to protect ECC-encrypted data once its on the chain. The HN;DL attack starts today. This is why the type of data that is being stored is critical. For example, if itā€™s my hand in poker, no big deal because that information wonā€™t matter over a short time horizon. I donā€™t care if everyone can read that in a few years. PII on the other hand may be much more sensitive information that I donā€™t ever want to leak.

Presumably the users of AVM Email use it because they donā€™t trust centralized servers to handle their data correctly. Putting ECC-encypted data on-chain, however, is definitely mishandling the data if it is sensitive.

35

I fully understand the point you raised, and I do think itā€™s a very valid one.
What concerns me more is that this analysis comes from a single perspective of use. And even though itā€™s a strong perspective (which I acknowledge), it ends up overlooking several other scenarios where email plays an important role.
It doesnā€™t have to be seen only as a personal or sensitive communication channel. It can function as a purely informational medium, a newsletter hub, a two-factor authentication component, or even as an integration layer within a stack of services built around the user of that email address.
In other words, reducing the project to a single use case ends up ignoring the flexibility it can have across different contexts.