Until recently I wasn't aware that the XMPP protocol specification was still being updated and up to date including things like read receipts, message reactions etc. I'd love to see the EU standarize communications with something like XMPP and something similar for voice/video. It would be amazing to not depend on clients like WhatsApp for my whole life.
I'm excited to try Movim and mobile XMPP clients with XMPP bridges like the one in the front page last week.
There was one beautiful moment where Google and Facebook supported XMPP so you could just set up your XMPP server and talk with people across the platforms but both decided to close their gardens for the usual reasons
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.
> 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.
> 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.
That's of course the tricky question. To a degree it might be a presentation thing that they are all shown equally.
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.
Yes, extensibility is XMPP’s curse. Don’t make something open and extensible for communication. Make it full featured and versioned so that users don’t have to deal with a stupid compatibility matrix.
Figured I'd chime in how pleasantly surprised I was with how well xmpp works for my narrow use case of an e2ee messenger between family members. Snikket is packaged with STUN/TURN out of the box, and to my surprise, a lot of family calls are going through the xmpp client. Perhaps there are pain points that I don't see, but xmpp's method for audio/video jingle works well.
Decentralized networks are very resistant to moderation. Don't like my rules? Go to someone else's server. Also blacklisting specific people from specific servers or whole servers in general is an uphill battle a lot like the email spam battle. It's very difficult to keep unwanted content out.
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.
Movim is great! I don't even use its microblogging features, but the chat part implements emoji message reactions* which are a very convenient way to acknowledge a message, and a way that everybody understands. It may look gadget-y and I suspect a lot of old school hackers might hate them, but I think that we should reckon that they are seen as a standard chat feature by non-techies. I used to be in the hate camp ("I don't want no 'facebook like' in my chats!") but after being forced to use MS teams at $EMPLOYER, I must admit I miss the feature in my (other than movim) XMPP clients.
What are the minimum viable requirements to be a social platform? Would it be different than a social media platform? To me this would be like irc with commands then every sent message/email would reply not to everyone but return something like a html page where the user could modify text commands based on the returned message.
Maybe an app (mobile or desktop) that connects to your email account and looks for messages with a certain key, collates them and creates a news feed + comments, then as you comment and reply to things it sends platform messages to the appropriate members?
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.
Since I'm replying 5 days late, I assume you'll never see this, but I'm so with you. I assume it's mainly a function of designing a suitable client. e2ee, federation, open standard, rich or plain text, media-capable, etc etc.
I like the idea but the landing page doesn't inspire confidence. My browser window is half with on a normal macbook and most of the text and images overlap making parts of it un-readable.
Depends on your definition of decentralization. Everybody seems to have either a personal best definition or simply aligns to some trendy product (that likely isn’t at all decentralized).
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.
The internet is composed of routers and switches, but those aren’t application servers. Telephones have a start point and an end point without a telephone server in the middle.
That makes no sense. A router is a box with routing rules and a few NICs on it. I have one setup in my house that's routing packets from an overlay LAN onto my home LAN. It is very much a piece of infrastructure that I own, and if I didn't control both ends, I would certainly want to be careful with operating it. If packets were E2E encrypted, I'd still be able to shut off my server and sever the link.
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.
Intermediaries cannot be avoided. Signals between devices are always open to interception whether that medium in between is copper, air, water, something else. That is completely out of scope. The goal is to prevent deliberate third parties and regard unintended third parties as security consideration.
Agreed that everyone has their own personal definition. With that in mind, I would never think of telephone as decentralized, at least not more than any other service provided by a company.
Let's assume you want to build a decentralized application according to my personal definition of decentralization: peer-to-peer with no application servers of any kind.
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.
There are overlay network projects that try to solve this problem. Take a look at Yggdrasil [1] which builds an overlay E2E encrypted, P2P mesh network. While you don't need TURN servers specifically, instead the overlay layer handles the P2P proxying for you. It still suffers from the same problem of necessitating intermediaries, and the fact that many peers don't actually have their own ASN so they aren't at the top of the network hierarchy, but makes it fairly "transparent" to use the network as everyone is assigned both a /128 and a /64 (for prefix delegation purposes) on the Yggdrasil network.
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.
I'm excited to try Movim and mobile XMPP clients with XMPP bridges like the one in the front page last week.