Open yanmaani opened 8 months ago
Indeed, prop 279 if i understand correctly is only a proposal and not actually implemented in the tor daemon.
So the fundamental problem here can be summarised by Zooko's Triangle
tldr: human-meaningful, decentralised, and secure; pick 2
onion service-ids (and by extension ricochet-ids) focused on decentralised and secure. I won't pretend to fully understand all of the parts of onion service system, but onion service-ids are a representation of the cryptographic public key of the cryptographic private key used to hand waving somehow register the onion service in the tor network.
Prop 279 basically comes in and says ok lets make a system that allows us to in someway solve the human meaningful problem at the detriment of the other two, in whatever way that makes sense for an application.
So, the current situation for some aspects of usability isn't great, but given Ricochet-Refresh's chosen audience/target demographic is journalists+whistleblowers, activists and the like, I think being cautious here is wise.
side-note: we should do some user-research and actually figure out what our users are using Ricochet-Refresh for in some sense
I don't particularly like the idea of adding a plugin-system or shim system to Ricochet-Refresh given both the security+privacy implications and the kind of shit-show we have now around the pluggable transports ecosystem.
Ricochet-refresh relies on v3 onions to uniquely identify contacts. This is secure, but not human-readable.
Within Tor, there is a specification for pluggable naming systems (proposal 279). A client to the
tor
daemon keeps a mapping of (TLD -> executable), then looks up queries for the known TLDs using the executable file specified in its configuration.The direct application of proposal 279 to RR would not be a good fit for its security model - it would be as if, in Signal, you could randomly have the key for a contact changed from beneath your feet. However, having ricochet act as the proposal 279 client would (to me) make perfect sense.
Basically: When trying to add a contact, currently, Ricochet-refresh could (alongside
ricochet:
) also support other prefixes. Then, if a query is made matching one of those prefixes, it would be redirected to the appropriate service.I propose to implement this by adding a new tab to the settings called "ID systems" or "naming", where the user can define which services to use (i.e.
nameid:
->/path/to/namecoin.shim
). Ricochet would query these services immediately upon trying to add the contact and turn it into an onion, which would be the only identifier stored durably. Then, if one or more services turn out to be both secure and easy to use, they could be officially integrated into Ricochet.