Movim – A decentralized social platform built on XMPP
github.com
github.com
I'm excited to try Movim and mobile XMPP clients with XMPP bridges like the one in the front page last week.
But XMPP is shitshow of million XEPs and massive matrix of which supports what. So just because in theory there is some feature you want it doesn't mean that your server and your client will work with it. That's terrible value proposition to anyone wanting to do anything in the space, you dont want to debug (and we did had to, when we used xmpp for our company chat) why user X using communicator Y on platform Z can't send attachment to your user on communicator Q.
XMPP needs to just sit the fuck down, gather the XEPs and put it into XMPP 3.0, with few feature sets that every client and server using it needs to support all at once, not picking and choosing.
So if you make text only chat client, it supports all of the formatting, all of the file send/receive, all of the MUC things, all of the E2E encryption things, all at once. And have one text formatting to support (Markdown seems to be winning here), not a bunch.
They do exactly that - https://xmpp.org/extensions/xep-0459.html
Easy to deploy solutions for common use cases like company chat are being worked on with projects like https://snikket.org/ (or well movim!)
Matrix: https://spec.matrix.org/latest/
You are welcome
The yearly compliance suites try that - and then IMHO fail a bit by offering too many variants.
E.g. to me, I'd expect a headline profile that's equivalent to "Advanced IM + Advanced Mobile". And I'm not sure the split into "Basic/Advanced" esp for mobile makes much sense. But I also can totally understand why people thought each of the distinctions was valuable, but that makes it feel a bit too comittee-style of trying to make everyone happy by including their variant and over-complicating the entire thing as a result. Certainly something I've seen happen to other specifications.
I hated XMPP with all my heart.
For example, conversations.im still lacks Message Reactions, Threads, and Publish-Subscribe:
https://github.com/iNPUTmice/Conversations/issues/3874
I'm unclear if ejabberd mod_sip is actually a bridge or something else entirely and jigasi seems pretty jitsi specific.
You can also join the official chatroom: movim@conference.movim.eu
That was my experience when looking at Matrix and Mastodon. So I am skeptical of projects like this.
That said the UI looks very nice and the idea very promising.
I've considered looking into maybe adding Movim into the mix; one of my friends can't be on public social media due to job reasons.
As long as you aren't looking for a platform with promoted follows vs just friends and family, it seems like a more ideal way to do so without having to worry about anyone else "owning" your network. Add encryption, etc as well if desired.
Email seemed to be the safest and most widely available means of async data exchange, with IMAP making it possible to sync between mobile and desktop easily enough.
I've tried everything! mo-Ctrl-Q, mo-Ctrl-X, mo-Alt-F4,, mo-F10 ...
My personal definition of decentralization is peer to peer without a server in the middle, like a telephone call. Nobody seems to like that definition because it’s extremely non-commercial.
Which is routed through centralized exchanges ...
If you want true P2P with no intermediaries, then you need a direct P2P technology like a direct Ethernet connection or an L1 radio link with encrypted packets (and even this is fraught with a single RF collision domain.) Otherwise you are also just using a "personal definition of decentralization" that you gatekept about in your comment.
1. To me this means IP address to IP address communication. But but but IPv4 NAT address: for this there are TURN servers which look pretty expensive. A TURN service provides application layer routing, like a proxy, to route data to a respective node on a private network.
2. I don't want to pay for TURN or deal with the extra layer, so I just write off nodes limited to a NAT IPv4 address on a separate subnet.
3. You need to account for session/relationship management. For this I am using a tiered model whereby nodes are assigned a group identity that allows for increases to access inversely proportional to autonomy.
4. You need some manner of trust validation. This is the piece social media doesn't know how to solve without some sort of centralized ledger. I am just using certificates and putting this liability directly onto the users to properly execute a text challenge response.
5. In a peer-to-peer decentralized model both ends run a listener for incoming connections on a fixed port. That sounds amazingly close to the definition of a server, but each connection is otherwise a client-to-client tunnel with a random client port on both ends. That means one end creates a client connection and points to a remote user running a listener. That listener spawns a connection to a client port and performs the checks to verify connection establishment, validation, anything else. After that initial processing on the listener you are left with a connection. If the connection is bidirectional both ends must listen for incoming data equivalently and must manage sessions and relationships equivalently.
Finally, you need to rethink how your prioritize software. Commercially software obtains value from that which you own, which is either a copyright on an application or data in a database. In a decentralized world data is that which you are willing to access or transmit and nothing more. The value is purely functional to your application and nothing for you to secure behind a subscription.
That said the value of a decentralized application comes down to three things:
* automation - whether the application eliminates manual effort
* transmission - whether the application can connect over a network in a way that resembles immediate local device access, such as real time bidirectional communication
* utility - does the application do something amazing, which is more than putting data on a screen. You have to think bigger than a webpage or a spreadsheet.
Once you solve for transmission and OS challenges end to end encryption is as simple as turning on your application.
At another level, Tor is essentially the same secure P2P network. While onion routing is used to route packets, fundamentally you don't need a publicly routable IPv4 or IPv6 address to receive packets. Instead peers onion route packets until the server with the correct keys can decrypt the packet.