That sounds very promising! Having two mobile devices with 5+ radios (2G, 3G, 4G, wifi, Bluetooth, NFC, ...) inside 5 cm from each other yet they can't easily talk directly to each other in a user friendly way is such a fail!

Like really, my Palm TX could do that via infraport!

So any effort to break this stalemate makes me very happy. :)

I have tried to understand the reason for this design limitation (no easy efficient peer to peer on phones) for a long time now.

I have come to the conclusion that the inability to communicate is not a fail but intended.

It seems like security and business interests are standing in the way, not primarily technical hurdles.

Mesh networking and service discovery are issues where technical solutions exist. But their application is slowed or blocked by network operators and phone/OS manufacturers to enforce a central authority and paying subscribers.

Privacy concerns are often used to explain these decisions, but I see those as mere excuses. Mesh node identifiers could just be randomly regenerated periodically or handled anonymously. Also firewall rules could easily ensure only authorized services can communicate.

It was interesting to observe how quickly similar P2P features were enabled in the fight against Covid-19 (contact tracing via BLE advertisement packets).

At the same time it is harder than ever to use, for example, Android's WiFi or Bluetooth in an App-controlled manner. Only the central authority, not the owner of the device nor independent App developers are apparently supposed to actually use the devices capabilities.

Quite frustrating.

I have been thinking about building a generic case/USB gadget to enable free communication, but such a solution would have many drawbacks versus using the internal radios.

Privacy concerns are real, but possibly misguided. Mesh networking will obviously reveal much more to people around you than the centralised model. But in return you get shrouded from centralised infrastructure. It's a legitimate trade-off and I imagine people preferring one way or the other. But instead of talking about a trade-off, we tend to reject ideas because one of the aspects would regress.

I also think it's intended by the people actually paying for development of the phone hardware and OS. Also iOS being fully proprietary and even the open parts of Android being effectively developed by a privileged group of Google engineers with zero community input for project direction does not help...

The involved parties want to sell you cloud services(hello Google!), to have you use up mobile data & calls/SMS (hello operators! ) and ideally to throw the phone away after a year or two (hello manufacturers).

And all they need to do is build a device OS combo that needlessly peddles data via cloud somewhere on the internet, has not data card slot and can't talk directly to similar device on the table next to it...

It still does not solve key distribution.

Matrix P2P removes the homeservers, but clients are still talking to each other through some medium that can impersonate them.

There's really no magic solution to solve this, you need either a trusted third-party (such as Certificate Authorities, who are expensive) or a Web of Trust (impractical for users).

Matrix's existing E2EE has identity verification as effectively one- or two-hop web-of-trust using QR codes or emoji comparisons. It's not impractical for users, because everyone's familiar these days with scanning a QR code as a mechanism for logging into an app (c.f. Discord, WhatsApp, Signal etc). So as long as you scan the people whose identity you care about, you're sorted, and it's much easier for normal users than the clunky old PGP signing parties of years gone by (plus it doesn't leak as much metadata, given it's just one or two hops of trust).

Can we get a arewep2pyet.org ? Maybe the wait would be more bearable ;)

Or if you prefer threats: "If I die from covid before matrix p2p is a thing, my ghost will haunt you for evar!".

excellent idea - have registered :)

For me it looks very weird and defeats the whole purpose of Matrix. I mean: it was designed from the ground as a federated network, similar to E-mail. Turning it into a completely different topology will not end well. If they want a P2P client, they should design it from the scratch. Otherwise it'll end up as a bunch of hacks glued with tape.

It wasn't designed exclusively as a federated network, tbh - we've been planning for P2P since pretty much day one; https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%... is a talk I gave in 2015 when Matrix was less than a year old on our plans to go P2P.

Personally, I think it's really nice that in P2P Matrix precisely the same client-server API is used as for normal Matrix, so all the work that goes into the Matrix client and E2EE etc is preserved without any changes at all. Instead, it just talks to a server running on localhost, which then replicates traffic around over the P2P overlay (in future using store-and-forward servers if the target server is offline). It's really not a bunch of hacks, thanks to Matrix being architected to make the replication transport & protocol pluggable from the outset.

Thanks, that's reassuring. I really like Matrix and don't want it to collapse because of lack of a vision.