MollyApr 23

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

Show threadMollyApr 23

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

Show thread🌸 lumi-nhac    🌱Apr 23
@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
Show threadd@nny disc@Apr 23
@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
grouplink

A generalization of the Signal cryptographic protocols for general message encryption without a central server.

Codeberg.org
Show threadd@nny disc@Apr 23
@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
Show threadd@nny disc@
@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
Apr 23 at 8:59pmWeb
Show thread🌸 lumi-nhac    🌱Apr 23
@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
Show threadd@nny disc@Apr 23
@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
Show thread🌸 lumi-nhac    🌱Apr 23
@hipsterelectron i don't think it needs to be fully p2p, it could just use servers as dumb relays, like deltachat and simplex do. going full p2p has its own set of problems, especially regarding mobile devices and connectivity

i'm totally open to chat about this more. i also won't be able to collaborate effectively as i lack the spoons right now. maybe in the future x)
Show threadLisPiApr 23
@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.