Mastodawn

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

Molly Apr 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.

Open to questions or suggestions.

@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

grouplink

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

Codeberg.org

@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 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

@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)

LisPi Apr 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.

@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