I believe cwtch[0] is essentially Ricochet, but with support for group chats and v3 addresses.

[0] https://cwtch.im/

Yup, saw them, they had even looked at using my Tor Go controller lib. I look forward to watching it develop towards end user friendliness. I am a fan of the project.

So my security knowledge is a bit lacking. Is there anything that would make using cwtch less secure than using Riochet by itself?

Just potential vulnerabilities in the implementation AFAIK.

Cwtch hasn't been audited whereas Ricochet has.

Tor can also be de-anonymized if a person controls a significant chunk of the network. However, if we keep changing the route constantly, (instead of establishing a static route during startup time and just reusing it, as tor does), we might make a much better and safer system. As you can expect, creating route takes time and defeats the purpose of IM.

Tor changes routes every 10 minutes.

Consider adding forward-secrecy and encrypting the payloads (beyond the Tor transport) as Richochet does neither.

> Consider adding forward-secrecy

Considering. But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point. Forward secrecy for the data at rest (i.e. in the DB) could have value but my current on-disk DB doesn't support this. But on the wire assumes MITM which should not be the case for user-to-onion. There is some defense in depth, but it's not something I'll target for MVP. There will be a built in data-expiration feature.

> and encrypting the payload

What does encrypting the payload help with when talking to an onion is already E2E encrypted? I do plan on encrypting at rest, but not in transit at least not at first. Could move to do TLS, but I'd be doubling Tor efforts because I'd probably just encrypt+sign w/ that same ed25519, so there'd be no real value.

> "But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point."

That's a problem with almost every messaging system. I wouldn't worry about that.

> "What does encrypting the payload help with when talking to an onion is already E2E encrypted?"

It would be a requirement of PFS, but I meant encrypt at rest - my mistake.

Have you published to git? I have been wanting to try Ricochet but its inactive state makes me nervous.

In very early stages (like too early to know what's going on or why I'm taking certain approaches). However, I have built a couple libraries I leverage. There is a Tor embedder/controller [0] (with a project assisting with statically linked Tor [1]) and there is a Go wrapper for locally encrypted Sqlite [2] (which I need to update). That Tor controller even has a gRPC example that shows the basic idea of starting an onion service and communicating over Tor.

0 - https://github.com/cretz/bine

1 - https://github.com/cretz/tor-static

2 - https://github.com/cretz/go-sqleet

Thanks for the links. I will check it out. Recently I created a hidden service using whonix but didn't get a chance to build the site itself. actually created a couple different types so I have a little, very little, experience in the creation and utilization of H.S. but I look forward to looking at your idea and work. The concept is something that has a lot of positive possibilities.