Post

OK, I wrote up a whole blog post with some more detailed thoughts on this. Curious if anything here resonates with other folks. Thanks to @iame.li, @dholms.at, and @bnewbold.net for helpful pointers and discussions! pckt.blog/b/bits-of-en...

deniability is worth keeping but i like the rest of this

Why do you think deniability is useful?

The more relevant questions are when is *non-deniability* useful? For whom? That capability is NOT a baseline expectation elsewhere online. The web + screenshots usually don't offer durable, attributable *proof* that someone possesses an authentic copy of what you once put online

Don’t discount the latter point — redistribution is what lets AT scale as well as it does. I’m surprised that people want to bake in a scaling limit that will force private things to be small.

If privacy is a spectrum, I tend to be most interested in use cases which operate at interpersonal scopes Aside from rent-seeking, what use cases would you find valuable for anything like "broadcast-scale privacy"? The very idea sounds like an oxymoron, so what am I missing?

PS: You may also want to take a closer look at how well syncers might scale, given that they only need a cert from one member to scan the entire space If you squint, couldn't they evolve to function as a members-only caching proxy layer, tied more closely to a space than an app?

Even on an interpersonal scale of users, if you imagine building say a collaborative editing platform, the number of records can scale very quickly. Also, one of the use cases here is subscriber-only feeds — is deniability worth limiting the number of subscribers you can support?

This is preservable with short term message authentication. Some early variants of OTR publishes the private keys after the session (the innovation of Signal, then textsecure, was making asynchronous messages equally protected). It's harder in group settings though