As some of you may know, we're building Flatline, a self‑hostable soft fork of the Signal Server. It lets you run a mostly Signal‑compatible server for research and private deployments.

We already run a Flatline server in Bahnhof cloud for internal development.

#Signal #mollyim #flatline

Now we're working on accounts without phone numbers, and the technical draft is public.

If you're interested or might ever want to run your own server, have a look.

https://github.com/mollyim/flatline-docs/blob/main/drafts/phone-less-registration.md

Open to questions or suggestions.

#Flatline

@mollyim this fucking rocks

@mollyim i also have some opinions about the new cryptosystem introduced by signal's new cryptographer and will be looking to implement a separate double ratchet implementation for separate reasons. i don't expect my implementation will be useful for the molly project but was wondering if there was any discussion about double ratchet vs spqr for this independent implementation

@mollyim Will this be able to connect with Signal users as well? Are voice/video on the agenda? If this was a simpler to set up/maintain solution than Matrix it could be a good way to do both a private comm server while still having a larger userbase to connect with from a single client.

@reflex @mollyim likely not. Signal doesn't like that kind of adversarial interop.

Perhaps the client could support having both accounts, though?

@mollyim “research and private deployments” i’m not super well read when it comes to security stuff or open source stuff, but like. is recreational use not an intended purpose?

@shroomie @mollyim if molly implements multi-account support and the ability aggregate contacts from accounts on signal and flatline servers (or federation across flatline servers, though i don't think the signal protocol can cope with this) that would be really cool

@mollyim this is on the way to make signal actually viable. if people could use it without a phone number and could choose which server to connect to

the next step would then be open federation, to liberate signal

@lumi @mollyim federation can be a hard problem as it implies group behaviors which are generally the source of matrix vulns. i would be curious what you mean by "liberate". i developed a proof of concept that uses signal like gpg to encrypt individual messages several years ago https://codeberg.org/cosmicexplorer/grouplink and could be assed to rebase it again but i think it would be more appropriate to reimplement double ratchet and x3dh from scratch at this point

@lumi @mollyim i think developing a group protocol on top of this basis of self-sovereign identity is more likely to be successful than trying to extend the molly server approach since one of the benefits of molly's work here is getting to share lots of peer-reviewed and audited code with signal

@lumi @mollyim possibly interested in collaborating on this but also possibly hoping to extend my work into an anonymous networking protocol to displace IP and not sure which API surface to cut at for that yet that would serve the purpose of group messaging

@hipsterelectron @mollyim afaik signal works a lot like deltachat and simplex, where it is mostly a point-to-point thing, with groups being done in a way where the client is doing the broadcasting to all members. correct me if i’m wrong, tho

federation here would then just mean servers relaying, i guess

signal has a few big issues, one being related to the other: it’s centralized and it requires phone numbers to sign up. if it were not centralized i’m sure the phone number requirement wouldn’t be enforceable anyways (and it should not be. it’s just wrong to require a phone number to sign up)

with liberating signal, i mean addressing those issues, making it viable for me to use and recommend

@lumi @mollyim yes that is how my code works which forks libsignal but it would be a significant change from signal's current architecture and i'm not sure how onboard the molly project would be for that (meredith whittaker fwiw has been supportive of my research but i don't think she's wrong to identify it a very large change that's hard to justify given signal's current model). if they are, then i'd love to help see that through. but right now, the server helps to enforce cryptographic requirements and that would need to be changed. it's not a terribly large one and your assumption is correct in general

@lumi @mollyim harassment is a problem on matrix and i would hard refuse to sign off on any federation technique that fails to address the issue. signal sidesteps it with phone numbers. it's going to be a problem with molly's work if someone makes a big server like mastodon dot social. my work explicitly does not handle connection or a chat interface and avoids producing the problem of harassment but does not solve it. i have ideas here but harassment is a form of ddos and needs to be addressed

@hipsterelectron @mollyim very interesting ideas :D

instant messaging protocols have been a special interest of mine for a long time now. i’ve mostly done deep dives in how xmpp, matrix, deltachat and simplex work. i used to develop xmpp software in a previous life

from all of my flip-flopping on what i think the best model is, i have settled on that i think the point-to-point model is likely best for dms and small groups. keep the server as dumb as possible. in small groups where the participants trust one-another, the threat model does not need to be very paranoid towards whoever is in it (but does for attackers outside of it, ofc)

for bigger spaces, i like what xmpp muc and irc do, where one server is the focal point of the room and coordinates everything. i do like xmpp a bit more here as the server you are on kinda acts like a bouncer

ended up just rambling a bit, eheh :3 a general purpose overlay network would also be very nice

@lumi that's not rambling i now understand your earlier posts better. i think it would be good to gauge what interest molly might have in the fully p2p approach at some point but probably to consider it a distinct proposal from this work for the time being. i am extremely serious about following up on this but i am also kind of insane so can't guarantee i can effectively collaborate. it might be good to chat more on the point to point approach bc i have a pretty specific idea about that and it seems like it's compatible with your specific idea here

@lumi @hipsterelectron @mollyim > in small groups where the participants trust one-another, the threat model does not need to be very paranoid towards whoever is in it (but does for attackers outside of it, ofc)


That provides less ambient trust and less insecurity than options that rely on more complex group keying.

Dropping a member is a single step operation.

Coordinating the drop would be necessary for "group" kick, but group keying is for efficiency and tradeoffs are made as a result.