17 ms·

Decentralize Messaging

151 points by wiggler00m 7y ago

kitd 7y ago
Mentioned in a separate thread, but DeltaChat [1] offers a WhatsApp-style messaging interface over standard email. [1] - https://delta.chat/en/ https://delta.chat/en/
- rapnie 7y ago
  Like the idea. It was discussed here: https://news.ycombinator.com/item?id=19216827 https://news.ycombinator.com/item?id=19216827
timw4mail 7y ago
Unfortunately, it's probably too late. Email caught on because it was the first option, and it's become ingrained in spite of itself. At this point the closest thing to a standard for person to person messaging is SMS... which like the old guard of ICQ, uses a number rather than a screen name. That said, I would love to see a good standard for person to person chat, especially one that doesn't rely on magic numbers.
jacob019 7y ago
I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.
- dijit 7y ago
  The issues mostly stem from: 1) not knowing what is supported on the server, or the other users server. 2) not handling mobile clients well (heavy battery use, weird deliverability issues.)
  - pmlnr 7y ago
    1 can be queried. 2 is BS with capital letters. See Converations and it's forks.
    - Andrew_nenakhov 7y ago
      2 is not BS, but not for the given reasons (heavy battery use/weird deliverability issues). 'Not handling mobile clients well' is true. Did you ever wonder why there are no (to date) XMPP clients on iOS that are not complete and utter shit? As a person who has first-hand knowledge of the matter, managing a team member tasked with the development of an iOS XMPP app (which is supposed to be NOT complete and utter shit), I tell you that creation of such app is impossible without reinvention of half of XMPP stack (basically every part that touches client-server interaction). Thankfully, s2s works rather fine in XMPP.
      - jacob019 7y ago
        Perhaps Apple deserves some of the blame here? Is the protocol just too chatty?
        ryukafalz 7y ago
        My understanding is it's because XMPP expects the client to be able to maintain a connection to the server, which is typically not possible on iOS. Apps on iOS are generally not permitted to run in the background, with a few limited exceptions.
        Andrew_nenakhov 7y ago
        Yes, exactly. And while currently there are ways to maintain a connection to a server on Android, it is clear that the platform is going to restrict this capability even further. Even now, if you run a background process, and start doing some memory-intensive operation, like taking a picture, your app is unceremoniously offloaded from memory, making you unable to receive messages, until the service permits a restart.
- ralls_ebfe 7y ago
  I moved to xmpp only for instant messaging over a year ago. At first it was met with great resistance by my contacts, but by now my family and almost every relevant friend installed conversations on their smartphone. I helped with the setup and provide them with access to my personal server. The growing public knowledge about privacy violations of the big services has made it very easy for others to grasp the reasoning behind my preference for decentralized services. I actually thought about using matrix, but it apparently "modern" means "resource hungry". My xmpp instance server runs on a small server with 2GiB Ram, with more than 1.5GiB being unused.
  - Arathorn 7y ago
    Yes, Synapse is resource hungry - but it also does a lot more than a typical XMPP server. Meanwhile, we're finally making progress with small footprint homeservers for Matrix. shrug
    - ppjet6 7y ago
      > a lot more Than allowing for messaging or "social network"-like features? From the user in practice, Matrix and XMPP (IM) are the same. These protocols might have made different technical choices but the user still only wants to send message and do various other things that both these protocol support. So not replicating all that data is actually a feature IMO.
  - thinkloop 7y ago
    From a privacy point of view, I would be more comfortable with google reading my messages than one of my buddies. Is your xmpp e2e?
    - pmlnr 7y ago
      Yes. It is. https://omemo.top/ https://omemo.top/
- pmlnr 7y ago
  Because then devs would need to follow rigorous standars with xml instead of "just building it". Yes, I'm full of anger. We had xmpp, pidgin, miranda, trillian. Now we have gazillion mobile only (no, a web gw through a server to your phone is NOT a desktop client) messaging, so let's throw matrix in to solve it, instead of building an xmpp client with up to date xep support. Xkcd 927 on steriods.
- Andrew_nenakhov 7y ago
  As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Also, it often happens that when a client developers need some feature that honestly should be done by a server, a developer still does this on a client, because it's all he has, with subpar results. Absent leadership from XSF also plays a role. This club now mostly cares about bureaucracy and following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there. That's why it is unlikely for any great product to appear under such guidance. We're trying a different approach, maybe we'll even succeed. If so, you'll hear about it on HN.
  - arendtio 7y ago
    How about Quicksy.im? https://play.google.com/store/apps/details?id=im.quicksy.client&hl=en_US https://play.google.com/store/apps/details?id=im.quicksy.cli...
    - Andrew_nenakhov 7y ago
      Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this: > a product, which can be easily deployed and will work consistently on every platform.
      - arendtio 7y ago
        Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-) Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp. One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably. So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)
- sneak 7y ago
  Google made it practical and offered widespread federation. It was not used by many people to talk outside of Google servers (federation ability went almost entirely unused), and it suffered from tons of inbound spam problems, so they shut it off. To answer your question directly though, XMPP doesn’t seem to be that great of a protocol. I’ve heard repeatedly that implementing it is a big mess, and that XML was a poor choice. I’m not sure that this is the reason that users don’t use it, though. It could be that these days, the client-server model is mostly obsolete, as due to battery constraints, phone users mostly rely on Apple or Google push messages to notify.
deleted 7y ago
[deleted]
ravenstine 7y ago
We could decentralize things more, but then people will point to decentralized communication and claim it's dangerous because it helps drug dealers and pedophiles.
- buboard 7y ago
  thats why its best to extend email . it's already decentralized and people don't claim it helps drug dealers. i think the worst part of centralized services is they made police and states complacent and depend on constant spying
  - deadbunny 7y ago
    For 99% of the population email is extremely centralized.
    - buboard 7y ago
      hm not really, thanks to corporate / institutional email silos . sure there is gmail, yahoo , outlook ... but also a huge long tail that is not going away
parvenu74 7y ago
Isn't this, at least in part, the goal of OStatus/Mastodon? It's a great idea but I find it humorous and ironic that many mastodon admins circulate block lists specifically meant to cut off nodes. I would prefer that users just use the block features available (and adding the ability for a user to block nodes or apply blocklists if they want to, but not for admins to make that decision for them).
- cjslep 7y ago
  It's a shame you say "Mastodon" when we want to say "ActivityPub". Federating an RDF graph is powerful.
zapf 7y ago
Does Matrix allow for anon communications?
- Arathorn 7y ago
  Yes, for better or worse.
zzo38computer 7y ago
Make using standardized and simply enough protocols, such as IRC, Message Send Protocol, NNTP, Zephyr, etc
- dmix 7y ago
  Like gtalk using XMPP?
  - zzo38computer 7y ago
    XMPP uses XML. IRC is simpler and can be used without any specialized software, and was designed like that, so that you can use without specialized software (I have used IRC on computers before installing a IRC client)
    - deleted 7y ago
      [deleted]
    - KaiserPro 7y ago
      typing PONG every ten minutes isn't entirely practicable
      - zzo38computer 7y ago
        I am aware, and is why I normally install a IRC client soon, but when I want to ask something first before installing a IRC client, it helps anyways.
bergstromm466 7y ago
Completely agree. For anyone who hasn’t come across it, check out the exciting work being done by developers of the Secure Scuttlebutt protocol: “Secure Scuttlebutt (SSB) is a peer-to peer communication protocol, mesh network, and self-hosted social media ecosystem. Each user hosts their own content and the content of the peers they follow, which provides fault tolerance and eventual consistency.[5] Messages are digitally signed and added to an append-only list of messages published by an author.[6] SSB is primarily used for implementing distributed social networks, and utilizes cryptography to assure that content remains unforged as it is propagated through the network.” Read more: https://en.wikipedia.org/wiki/Secure_Scuttlebutt https://en.wikipedia.org/wiki/Secure_Scuttlebutt Join us! There is a fully functioning client, and bustling Solarpunk community: http://scuttlebutt.nz http://scuttlebutt.nz
- ElFitz 7y ago
  I'm really worried about the total amount of data each user will end up lugging around though. Also, append only => no deletes, correct?
  - thulecitizen 7y ago
    Yes, no deletes. Since there is no company in the middle, the GDPR rules don't apply to this P2P network, so it isn't an issue legally (in Europe). This is something that will probably take some puzzling to get to a sustainable mechanism. The strategy I've heard talked about most often is to append metadata that marks it as 'deleted', so when things populate or 'gossip' further, it won't show up in the user interface. Instead it's labeled as 'archived' or 'deleted', or has a link to it's replacement.
    - masukomi 7y ago
      It should be noted that while you can't delete / edit messages you _can_ delete blobs (binary attachments). They'll come back if you load a post that references them, but that's where the majority of size comes from and it is manageable. Also, how much you download is related to how many people you follow, and text doesn't take up a ton of space.
coding123 7y ago
xkcd 927, I'm not even going to link it because you know what it is.
aey 7y ago
It feels like we are saturated by messengers and social networks. Twitter, fb, slack, discord, matrix, signal, whatsapp, wechat, telegram... I am not sure what decentralization could bring there.
adrianmonk 7y ago
Protocols and privacy and chat features are all great, but let's not lose sight of the two absolutely killer essential features of every successful chat app / system: (1) The address book. (2) The easiest possible signup and setup. More generally for #1, whatever method(s) you use to find people's contact information and connect with them. Without that, you could have created the perfect chat experience in every way, but people still won't use it. Because their friends aren't on it and/or they can't find their friends. A ton of chat apps fail because engineers sit around talking about how to architect things, when the truth is that once you've gotten past the almost-insurmountable hurdle of getting two users onto the system and starting a conversation, the actual mechanism for actually sending messages back and forth is not much more than an implementation detail. Not that those things aren't important, but they are like 10% of the formula for success, and the other 90% is getting to the point where they can start a chat session. People's primary need is to communicate. With the people they want or need to communicate with. And via the contact information they have available. (Exchanging contact info for a new service offline is a huge hurdle.) A better experience is better, but at the end of the day, these other concerns will nearly always win out. So you don't get very far trying to use a superior experience as leverage to get people using it. You need to attack that problem more directly.
- _nothing 7y ago
  So true. One of my most active channels of communication is actually Instagram's chat despite it lacking many features I prefer in a messaging service like a desktop/browser interface and search functionality. But it's what my friends use, more actively than Facebook even, and so it's what I use. If you have Instagram then you already have this messenger, so it becomes a no-brainer.
- stevenicr 7y ago
  1 - this is a good point, but I'd like to expand on it - it does not have to be address book. I have helped thousands of people exchange contact info after meeting in various niche chat rooms first, but you can flip that and have your irl friends meet you in decn-chat dot org click the 808game room, we can meet in there and pm/dm a code word or something and make each other contacts in various ways. Your point is something to keep in mind though, ultimately I think we also need apps that can display a qr code like a one time pad to give someone contact details or any chat rooms to meetup in, Other methods of exchanging info about contact and chat room / chat app options should be added to whatever is going to be really good. 2 - I really agree with this, I spent some money and time on rocketchat development to give an optional 'open lobby' to anyone who enters, just pick a name and you are in.. then if you want extra abilities you can add an email or verify or whatever. easy to get in is important indeed.
jasonzemos 7y ago
> messaging apps are all the same, making them easy targets for standardization and interoperability. This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized services? Better develop them rapidly to keep up. Should they stagnate to maintain interoperability across an ecosystem? Good luck being competitive. We haven't even gotten to the features themselves and I promise you there will be irreconcilable differences. Does the protocol maintain message history or is it ephemeral? What is the privacy model? Can we delete messages on other servers due to GDPR? When you spend time at the business end of the messaging space, these dichotomies flow endlessly, without consensus, and they cover the entire horizon of the space. If you think you know the answers to these questions, you don't, because you're solving the wrong problem. If you want to decentralize messaging you have to solve the problem of how to agree to disagree while maintaining interoperability for a shared experience. Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. That doesn't work because you can't lose social information. Matrix has failed to solve this problem. We need a new approach. What will emerge to finally conquer this space?
- johnmorrison 7y ago
  I feel like you're overestimating the differentiation and not accounting for the fact that 99% of the population basically just uses the minimal subset of features (sending plain text and images) Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good. > Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. Which service doesn't show emojis? Literally every mainstream mobile operating system and desktop browser supports emojis as regular text.
  - jasonzemos 7y ago
    > the fact that 99% of the population basically just uses the minimal subset of features The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational and relative. > Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good. This has proven to result in an unacceptable user experience throughout the history of messaging. When a system loses social information from the environment it is no longer an effective communication tool. Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC client) that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.
hardwaresofton 7y ago
> I see two promising and complementary paths to decentralized messaging: building on the new and shiny Matrix protocol, and gradually extending email. COI is chat over IMAP[0], I think it's one of the best solutions I've seen in the sapace. [0]: https://www.coi-dev.org/ https://www.coi-dev.org/
rolleiflex 7y ago
This is what I’m working on with Aether (https://getaether.net https://getaether.net). A mass-communication method owned by no one, like email is owned by no one. It’s a modern, decentralised Usenet. I used to call it ‘email for mass communication’ but it confused people, since it’s not based on email, so I stopped calling it that. That’s the goal though. I also gave a talk on it at the Internet Archive last week, if you want a quick intro in video from. https://archive.org/details/12120iadweb https://archive.org/details/12120iadweb (My part starts at 1:13:30). If you have any questions, happy to answer.
- gojomo 7y ago
  Thanks for your presentation at that meetup! It's definitely one of the most radically-decentralized & technically-principled projects, so it was good to see it alongside other presenters there, like Matrix (definitely headed in the right direction) & Planetary (built on similarly-principled Secure Scuttlebutt).
  - rolleiflex 7y ago
    Totally, always a pleasure to talk at the Archive — not only just because of the like-minded people but also because I get to keep these recordings and pass around, and that's super useful in quickly explaining what it is.
- skyfaller 7y ago
  "In Aether, spam prevention is accomplished by requiring proofs of work". Now, I recognize that regular e-mail uses proof of work as a spam prevention measure these days, so I don't want to be too harsh on a decentralized alternative. That said, I've watched the energy expenditures of Bitcoin etc. with alarm, and I've become very concerned about the sustainability of anything using proof of work if it should become popular. Fundamentally proof of work makes people waste energy in order to accomplish tasks such as sending messages, at a time where we need to use as little energy as possible to reduce emissions. Have you considered sustainability at all with Aether? Have you considered any alternatives to proof of work for dealing with spam?
sagichmal 7y ago
It is astonishing to me that, after skimming the spec, anyone believes Matrix is the future. Or ActivityPub. Or XMPP. The future of messaging, decentralized or not, is certainly something with a tractable protocol.
- ppjet6 7y ago
  I agree, and this is one of the reasons I use (and contribute to) XMPP. For the Extensibility part.
jejei992o 7y ago
Messaging already is decentralized in that a number of open protocols can be independently implemented. It’s possible right now to clone a fully functioning XMPP stack from Github into Kubernetes in a day. What’s constantly leading us to centralized platforms is the political ownership model. A new protocol isn’t going to avoid the social gravity that comes with being a popular implementer who is then anointed with unelected political weight in exchange for changes in law to help them hang onto power. Engineers could stand to meditate on how ideas like DRY can be applied to more than just coding.
johnmorrison 7y ago
I'm working on a sort of ancillary project which may help with this at Valyrio [https://valyr.io https://valyr.io] Counter-intuitively, the current goal is to centralize the messaging interface, providing a common platform for users who are willing to pay for a consolidated system that saves time and confusion, and to reduce the waste of niche use cases (e.g. having the entire [name here] messaging app on your phone because one weird family member or friend insists on using it) Bringing email, text, and (aspirationally) all other messaging systems into one. In doing this, we cannot possibly hope to uniquely integrate each of the countless hundreds of services with their weird quirks and formats, so I aim to establish a standardized language for async messages equipped with the basic common features and extensions for prevalent (but not universal) features like read receipts, "liking/reacting" to messages, etc It would be really cool to open up that standard to the world if we do a good job of designing it, or collaborate with anyone else who wants to participate in this goal. Our core service will be a niche, paid, closed system, but the underlying language I would like to be open source and interoperable with whatever else turns out to develop (Twitter's new endeavor and Matrix are the two efforts I am most aware of) After all, Valyrio means Language I've also been working on an adjacent concept with [https://jwmza.com/polymath https://jwmza.com/polymath], which is a new comprehensive markup language meant to define long-term compatible, human readable documents and websites/document structures which intermix existing standards like (La)TeX, HTML, CSS, Markdown etc. Perhaps the underlying language and concepts here will mix with the effort to decentralize messaging as well, as messaging is fundamentally the asynchronous bidirectional transfer of documents of mostly text and sometimes other media or information.
egypturnash 7y ago
I miss the days when one chat app could easily connect to multiple protocols. I didn’t care if my friends had AIM or Yahoo or ICQ or whatever, they all showed up as a tab in Adium’s window and a name on its floating buddy list.
- stingraycharles 7y ago
  I’ve been using Franz for a while for this purpose. While it’s not exactly the same (it launches a process per application), it is very convenient to have all of them in a single place. https://meetfranz.com/ https://meetfranz.com/
- VvR-Ox 7y ago
  Matrix has bridges to solve this: https://matrix.org/bridges/ https://matrix.org/bridges/
- johnmorrison 7y ago
  Building this with Valyrio [1] [1] https://valyr.io https://valyr.io
marknadal 7y ago
I talked to Twitter's CTO, Parag. He said the move is to specifically reduce fragmentation in public conversation. I'm in the decentralized (dWeb) community (we have 10M+ users monthly, in-production, running thru GUN) and admittedly, I think we all get distracted with the war cry of privacy, p2p-for-sake-of-p2p, etc. but is not many other people's end goals.
max_ 7y ago
Social media has more problems besides the need to “decentralize” The biggest problem with social media is how it is ruining our mental health. It’s sad that almost no one looking in to this.
edhelas 7y ago
> These extensions could include: delivery receipts => XEP-0184: Message Delivery Receipts optional read receipts => same as above user presence information => XMPP RFC binary serialization for efficiency and extensibility => XEP-0231: Bits of Binary end-to-end encryption => XEP-0373: OpenPGP for XMPP, XEP-0384: OMEMO Encryption, XEP-0378: OTR Discovery WebRTC signalling for negotiating VOIP and video chat => XEP-0343: Signaling WebRTC datachannels in Jingle signed introduction tokens to reduce spam => ? a standard extension mechanism => https://xmpp.org/extensions/ Can we just stop prettending that XMPP is not ready and/or outdated, all those things are there, used and implemented in more clients than Matrix has. Doing decentralized social media, on XMPP, is possible. Take XEP-0060: Publish-Subscribe, add Atom 1.0 (yes it's the power of XML, you can put a standard in another) and boom you have a social network with feeds, comments, subscriptions and everything, fully ready. I'm doing that for years with Movim https://movim.eu/ https://movim.eu/. The several major XMPP servers are handling that perfectly as well. How many Matrix servers are out there ? One, that is still in beta (Synapse). XMPP is standard (IETF wise), is already massively deployed, is used by universities, governments, companies…, is exensible, is stable and is maintained by a big and motivated community. Don't reinvent the wheel once more, just implement the standards.
- ajconway 7y ago
  How do you handle push notifications with XMPP? > How many Matrix servers are out there On a side note, that's not fair. Every project has to start somewhere and it might be difficult to gain traction. It doesn't mean that it has no chance of evolving into the greatest thing possible in its market, dwarfing once popular competition, simply because it didn't come first.
  - Reventlov 7y ago
    > How do you handle push notifications with XMPP? XEP 0357, implemented in servers ( https://modules.prosody.im/mod_cloud_notify.html https://modules.prosody.im/mod_cloud_notify.html for prosody, for example), and implemented by clients ( https://github.com/siacs/Conversations/issues/1171 https://github.com/siacs/Conversations/issues/1171, for conversations for example). Conversations also uses XEP 0198 and XEP 0352 for battery optimization: https://conversations.im/#optimizations https://conversations.im/#optimizations

151 points by wiggler00m 7y ago

kitd 7y ago

Mentioned in a separate thread, but DeltaChat [1] offers a WhatsApp-style messaging interface over standard email. [1] - https://delta.chat/en/ https://delta.chat/en/

rapnie 7y ago
Like the idea. It was discussed here: https://news.ycombinator.com/item?id=19216827 https://news.ycombinator.com/item?id=19216827

timw4mail 7y ago

Unfortunately, it's probably too late. Email caught on because it was the first option, and it's become ingrained in spite of itself. At this point the closest thing to a standard for person to person messaging is SMS... which like the old guard of ICQ, uses a number rather than a screen name. That said, I would love to see a good standard for person to person chat, especially one that doesn't rely on magic numbers.

jacob019 7y ago

I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.

dijit 7y ago
The issues mostly stem from: 1) not knowing what is supported on the server, or the other users server. 2) not handling mobile clients well (heavy battery use, weird deliverability issues.)
- pmlnr 7y ago
  1 can be queried. 2 is BS with capital letters. See Converations and it's forks.
  - Andrew_nenakhov 7y ago
    2 is not BS, but not for the given reasons (heavy battery use/weird deliverability issues). 'Not handling mobile clients well' is true. Did you ever wonder why there are no (to date) XMPP clients on iOS that are not complete and utter shit? As a person who has first-hand knowledge of the matter, managing a team member tasked with the development of an iOS XMPP app (which is supposed to be NOT complete and utter shit), I tell you that creation of such app is impossible without reinvention of half of XMPP stack (basically every part that touches client-server interaction). Thankfully, s2s works rather fine in XMPP.
    - jacob019 7y ago
      Perhaps Apple deserves some of the blame here? Is the protocol just too chatty?
      - ryukafalz 7y ago
        My understanding is it's because XMPP expects the client to be able to maintain a connection to the server, which is typically not possible on iOS. Apps on iOS are generally not permitted to run in the background, with a few limited exceptions.
        Andrew_nenakhov 7y ago
        Yes, exactly. And while currently there are ways to maintain a connection to a server on Android, it is clear that the platform is going to restrict this capability even further. Even now, if you run a background process, and start doing some memory-intensive operation, like taking a picture, your app is unceremoniously offloaded from memory, making you unable to receive messages, until the service permits a restart.
ralls_ebfe 7y ago
I moved to xmpp only for instant messaging over a year ago. At first it was met with great resistance by my contacts, but by now my family and almost every relevant friend installed conversations on their smartphone. I helped with the setup and provide them with access to my personal server. The growing public knowledge about privacy violations of the big services has made it very easy for others to grasp the reasoning behind my preference for decentralized services. I actually thought about using matrix, but it apparently "modern" means "resource hungry". My xmpp instance server runs on a small server with 2GiB Ram, with more than 1.5GiB being unused.
- Arathorn 7y ago
  Yes, Synapse is resource hungry - but it also does a lot more than a typical XMPP server. Meanwhile, we're finally making progress with small footprint homeservers for Matrix. shrug
  - ppjet6 7y ago
    > a lot more Than allowing for messaging or "social network"-like features? From the user in practice, Matrix and XMPP (IM) are the same. These protocols might have made different technical choices but the user still only wants to send message and do various other things that both these protocol support. So not replicating all that data is actually a feature IMO.
- thinkloop 7y ago
  From a privacy point of view, I would be more comfortable with google reading my messages than one of my buddies. Is your xmpp e2e?
  - pmlnr 7y ago
    Yes. It is. https://omemo.top/ https://omemo.top/
pmlnr 7y ago
Because then devs would need to follow rigorous standars with xml instead of "just building it". Yes, I'm full of anger. We had xmpp, pidgin, miranda, trillian. Now we have gazillion mobile only (no, a web gw through a server to your phone is NOT a desktop client) messaging, so let's throw matrix in to solve it, instead of building an xmpp client with up to date xep support. Xkcd 927 on steriods.
Andrew_nenakhov 7y ago
As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Also, it often happens that when a client developers need some feature that honestly should be done by a server, a developer still does this on a client, because it's all he has, with subpar results. Absent leadership from XSF also plays a role. This club now mostly cares about bureaucracy and following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there. That's why it is unlikely for any great product to appear under such guidance. We're trying a different approach, maybe we'll even succeed. If so, you'll hear about it on HN.
- arendtio 7y ago
  How about Quicksy.im? https://play.google.com/store/apps/details?id=im.quicksy.client&hl=en_US https://play.google.com/store/apps/details?id=im.quicksy.cli...
  - Andrew_nenakhov 7y ago
    Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this: > a product, which can be easily deployed and will work consistently on every platform.
    - arendtio 7y ago
      Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-) Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp. One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably. So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)
sneak 7y ago
Google made it practical and offered widespread federation. It was not used by many people to talk outside of Google servers (federation ability went almost entirely unused), and it suffered from tons of inbound spam problems, so they shut it off. To answer your question directly though, XMPP doesn’t seem to be that great of a protocol. I’ve heard repeatedly that implementing it is a big mess, and that XML was a poor choice. I’m not sure that this is the reason that users don’t use it, though. It could be that these days, the client-server model is mostly obsolete, as due to battery constraints, phone users mostly rely on Apple or Google push messages to notify.

deleted 7y ago

[deleted]

ravenstine 7y ago

We could decentralize things more, but then people will point to decentralized communication and claim it's dangerous because it helps drug dealers and pedophiles.

buboard 7y ago
thats why its best to extend email . it's already decentralized and people don't claim it helps drug dealers. i think the worst part of centralized services is they made police and states complacent and depend on constant spying
- deadbunny 7y ago
  For 99% of the population email is extremely centralized.
  - buboard 7y ago
    hm not really, thanks to corporate / institutional email silos . sure there is gmail, yahoo , outlook ... but also a huge long tail that is not going away

parvenu74 7y ago

Isn't this, at least in part, the goal of OStatus/Mastodon? It's a great idea but I find it humorous and ironic that many mastodon admins circulate block lists specifically meant to cut off nodes. I would prefer that users just use the block features available (and adding the ability for a user to block nodes or apply blocklists if they want to, but not for admins to make that decision for them).

cjslep 7y ago
It's a shame you say "Mastodon" when we want to say "ActivityPub". Federating an RDF graph is powerful.

zapf 7y ago

Does Matrix allow for anon communications?

Arathorn 7y ago
Yes, for better or worse.

zzo38computer 7y ago

Make using standardized and simply enough protocols, such as IRC, Message Send Protocol, NNTP, Zephyr, etc

dmix 7y ago
Like gtalk using XMPP?
- zzo38computer 7y ago
  XMPP uses XML. IRC is simpler and can be used without any specialized software, and was designed like that, so that you can use without specialized software (I have used IRC on computers before installing a IRC client)
  - deleted 7y ago
    [deleted]
  - KaiserPro 7y ago
    typing PONG every ten minutes isn't entirely practicable
    - zzo38computer 7y ago
      I am aware, and is why I normally install a IRC client soon, but when I want to ask something first before installing a IRC client, it helps anyways.

bergstromm466 7y ago

Completely agree. For anyone who hasn’t come across it, check out the exciting work being done by developers of the Secure Scuttlebutt protocol: “Secure Scuttlebutt (SSB) is a peer-to peer communication protocol, mesh network, and self-hosted social media ecosystem. Each user hosts their own content and the content of the peers they follow, which provides fault tolerance and eventual consistency.[5] Messages are digitally signed and added to an append-only list of messages published by an author.[6] SSB is primarily used for implementing distributed social networks, and utilizes cryptography to assure that content remains unforged as it is propagated through the network.” Read more: https://en.wikipedia.org/wiki/Secure_Scuttlebutt https://en.wikipedia.org/wiki/Secure_Scuttlebutt Join us! There is a fully functioning client, and bustling Solarpunk community: http://scuttlebutt.nz http://scuttlebutt.nz

ElFitz 7y ago
I'm really worried about the total amount of data each user will end up lugging around though. Also, append only => no deletes, correct?
- thulecitizen 7y ago
  Yes, no deletes. Since there is no company in the middle, the GDPR rules don't apply to this P2P network, so it isn't an issue legally (in Europe). This is something that will probably take some puzzling to get to a sustainable mechanism. The strategy I've heard talked about most often is to append metadata that marks it as 'deleted', so when things populate or 'gossip' further, it won't show up in the user interface. Instead it's labeled as 'archived' or 'deleted', or has a link to it's replacement.
  - masukomi 7y ago
    It should be noted that while you can't delete / edit messages you _can_ delete blobs (binary attachments). They'll come back if you load a post that references them, but that's where the majority of size comes from and it is manageable. Also, how much you download is related to how many people you follow, and text doesn't take up a ton of space.

coding123 7y ago

xkcd 927, I'm not even going to link it because you know what it is.

aey 7y ago

It feels like we are saturated by messengers and social networks. Twitter, fb, slack, discord, matrix, signal, whatsapp, wechat, telegram... I am not sure what decentralization could bring there.

adrianmonk 7y ago

Protocols and privacy and chat features are all great, but let's not lose sight of the two absolutely killer essential features of every successful chat app / system: (1) The address book. (2) The easiest possible signup and setup. More generally for #1, whatever method(s) you use to find people's contact information and connect with them. Without that, you could have created the perfect chat experience in every way, but people still won't use it. Because their friends aren't on it and/or they can't find their friends. A ton of chat apps fail because engineers sit around talking about how to architect things, when the truth is that once you've gotten past the almost-insurmountable hurdle of getting two users onto the system and starting a conversation, the actual mechanism for actually sending messages back and forth is not much more than an implementation detail. Not that those things aren't important, but they are like 10% of the formula for success, and the other 90% is getting to the point where they can start a chat session. People's primary need is to communicate. With the people they want or need to communicate with. And via the contact information they have available. (Exchanging contact info for a new service offline is a huge hurdle.) A better experience is better, but at the end of the day, these other concerns will nearly always win out. So you don't get very far trying to use a superior experience as leverage to get people using it. You need to attack that problem more directly.

_nothing 7y ago
So true. One of my most active channels of communication is actually Instagram's chat despite it lacking many features I prefer in a messaging service like a desktop/browser interface and search functionality. But it's what my friends use, more actively than Facebook even, and so it's what I use. If you have Instagram then you already have this messenger, so it becomes a no-brainer.
stevenicr 7y ago
1 - this is a good point, but I'd like to expand on it - it does not have to be address book. I have helped thousands of people exchange contact info after meeting in various niche chat rooms first, but you can flip that and have your irl friends meet you in decn-chat dot org click the 808game room, we can meet in there and pm/dm a code word or something and make each other contacts in various ways. Your point is something to keep in mind though, ultimately I think we also need apps that can display a qr code like a one time pad to give someone contact details or any chat rooms to meetup in, Other methods of exchanging info about contact and chat room / chat app options should be added to whatever is going to be really good. 2 - I really agree with this, I spent some money and time on rocketchat development to give an optional 'open lobby' to anyone who enters, just pick a name and you are in.. then if you want extra abilities you can add an email or verify or whatever. easy to get in is important indeed.

jasonzemos 7y ago

> messaging apps are all the same, making them easy targets for standardization and interoperability. This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized services? Better develop them rapidly to keep up. Should they stagnate to maintain interoperability across an ecosystem? Good luck being competitive. We haven't even gotten to the features themselves and I promise you there will be irreconcilable differences. Does the protocol maintain message history or is it ephemeral? What is the privacy model? Can we delete messages on other servers due to GDPR? When you spend time at the business end of the messaging space, these dichotomies flow endlessly, without consensus, and they cover the entire horizon of the space. If you think you know the answers to these questions, you don't, because you're solving the wrong problem. If you want to decentralize messaging you have to solve the problem of how to agree to disagree while maintaining interoperability for a shared experience. Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. That doesn't work because you can't lose social information. Matrix has failed to solve this problem. We need a new approach. What will emerge to finally conquer this space?

johnmorrison 7y ago
I feel like you're overestimating the differentiation and not accounting for the fact that 99% of the population basically just uses the minimal subset of features (sending plain text and images) Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good. > Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. Which service doesn't show emojis? Literally every mainstream mobile operating system and desktop browser supports emojis as regular text.
- jasonzemos 7y ago
  > the fact that 99% of the population basically just uses the minimal subset of features The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational and relative. > Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good. This has proven to result in an unacceptable user experience throughout the history of messaging. When a system loses social information from the environment it is no longer an effective communication tool. Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC client) that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.

hardwaresofton 7y ago

> I see two promising and complementary paths to decentralized messaging: building on the new and shiny Matrix protocol, and gradually extending email. COI is chat over IMAP[0], I think it's one of the best solutions I've seen in the sapace. [0]: https://www.coi-dev.org/ https://www.coi-dev.org/

rolleiflex 7y ago

This is what I’m working on with Aether (https://getaether.net https://getaether.net). A mass-communication method owned by no one, like email is owned by no one. It’s a modern, decentralised Usenet. I used to call it ‘email for mass communication’ but it confused people, since it’s not based on email, so I stopped calling it that. That’s the goal though. I also gave a talk on it at the Internet Archive last week, if you want a quick intro in video from. https://archive.org/details/12120iadweb https://archive.org/details/12120iadweb (My part starts at 1:13:30). If you have any questions, happy to answer.

gojomo 7y ago
Thanks for your presentation at that meetup! It's definitely one of the most radically-decentralized & technically-principled projects, so it was good to see it alongside other presenters there, like Matrix (definitely headed in the right direction) & Planetary (built on similarly-principled Secure Scuttlebutt).
- rolleiflex 7y ago
  Totally, always a pleasure to talk at the Archive — not only just because of the like-minded people but also because I get to keep these recordings and pass around, and that's super useful in quickly explaining what it is.
skyfaller 7y ago
"In Aether, spam prevention is accomplished by requiring proofs of work". Now, I recognize that regular e-mail uses proof of work as a spam prevention measure these days, so I don't want to be too harsh on a decentralized alternative. That said, I've watched the energy expenditures of Bitcoin etc. with alarm, and I've become very concerned about the sustainability of anything using proof of work if it should become popular. Fundamentally proof of work makes people waste energy in order to accomplish tasks such as sending messages, at a time where we need to use as little energy as possible to reduce emissions. Have you considered sustainability at all with Aether? Have you considered any alternatives to proof of work for dealing with spam?

sagichmal 7y ago

It is astonishing to me that, after skimming the spec, anyone believes Matrix is the future. Or ActivityPub. Or XMPP. The future of messaging, decentralized or not, is certainly something with a tractable protocol.

ppjet6 7y ago
I agree, and this is one of the reasons I use (and contribute to) XMPP. For the Extensibility part.

jejei992o 7y ago

Messaging already is decentralized in that a number of open protocols can be independently implemented. It’s possible right now to clone a fully functioning XMPP stack from Github into Kubernetes in a day. What’s constantly leading us to centralized platforms is the political ownership model. A new protocol isn’t going to avoid the social gravity that comes with being a popular implementer who is then anointed with unelected political weight in exchange for changes in law to help them hang onto power. Engineers could stand to meditate on how ideas like DRY can be applied to more than just coding.

johnmorrison 7y ago

I'm working on a sort of ancillary project which may help with this at Valyrio [https://valyr.io https://valyr.io] Counter-intuitively, the current goal is to centralize the messaging interface, providing a common platform for users who are willing to pay for a consolidated system that saves time and confusion, and to reduce the waste of niche use cases (e.g. having the entire [name here] messaging app on your phone because one weird family member or friend insists on using it) Bringing email, text, and (aspirationally) all other messaging systems into one. In doing this, we cannot possibly hope to uniquely integrate each of the countless hundreds of services with their weird quirks and formats, so I aim to establish a standardized language for async messages equipped with the basic common features and extensions for prevalent (but not universal) features like read receipts, "liking/reacting" to messages, etc It would be really cool to open up that standard to the world if we do a good job of designing it, or collaborate with anyone else who wants to participate in this goal. Our core service will be a niche, paid, closed system, but the underlying language I would like to be open source and interoperable with whatever else turns out to develop (Twitter's new endeavor and Matrix are the two efforts I am most aware of) After all, Valyrio means Language I've also been working on an adjacent concept with [https://jwmza.com/polymath https://jwmza.com/polymath], which is a new comprehensive markup language meant to define long-term compatible, human readable documents and websites/document structures which intermix existing standards like (La)TeX, HTML, CSS, Markdown etc. Perhaps the underlying language and concepts here will mix with the effort to decentralize messaging as well, as messaging is fundamentally the asynchronous bidirectional transfer of documents of mostly text and sometimes other media or information.

egypturnash 7y ago

I miss the days when one chat app could easily connect to multiple protocols. I didn’t care if my friends had AIM or Yahoo or ICQ or whatever, they all showed up as a tab in Adium’s window and a name on its floating buddy list.

stingraycharles 7y ago
I’ve been using Franz for a while for this purpose. While it’s not exactly the same (it launches a process per application), it is very convenient to have all of them in a single place. https://meetfranz.com/ https://meetfranz.com/
VvR-Ox 7y ago
Matrix has bridges to solve this: https://matrix.org/bridges/ https://matrix.org/bridges/
johnmorrison 7y ago
Building this with Valyrio [1] [1] https://valyr.io https://valyr.io

marknadal 7y ago

I talked to Twitter's CTO, Parag. He said the move is to specifically reduce fragmentation in public conversation. I'm in the decentralized (dWeb) community (we have 10M+ users monthly, in-production, running thru GUN) and admittedly, I think we all get distracted with the war cry of privacy, p2p-for-sake-of-p2p, etc. but is not many other people's end goals.

max_ 7y ago

Social media has more problems besides the need to “decentralize” The biggest problem with social media is how it is ruining our mental health. It’s sad that almost no one looking in to this.

edhelas 7y ago

> These extensions could include: delivery receipts => XEP-0184: Message Delivery Receipts optional read receipts => same as above user presence information => XMPP RFC binary serialization for efficiency and extensibility => XEP-0231: Bits of Binary end-to-end encryption => XEP-0373: OpenPGP for XMPP, XEP-0384: OMEMO Encryption, XEP-0378: OTR Discovery WebRTC signalling for negotiating VOIP and video chat => XEP-0343: Signaling WebRTC datachannels in Jingle signed introduction tokens to reduce spam => ? a standard extension mechanism => https://xmpp.org/extensions/ Can we just stop prettending that XMPP is not ready and/or outdated, all those things are there, used and implemented in more clients than Matrix has. Doing decentralized social media, on XMPP, is possible. Take XEP-0060: Publish-Subscribe, add Atom 1.0 (yes it's the power of XML, you can put a standard in another) and boom you have a social network with feeds, comments, subscriptions and everything, fully ready. I'm doing that for years with Movim https://movim.eu/ https://movim.eu/. The several major XMPP servers are handling that perfectly as well. How many Matrix servers are out there ? One, that is still in beta (Synapse). XMPP is standard (IETF wise), is already massively deployed, is used by universities, governments, companies…, is exensible, is stable and is maintained by a big and motivated community. Don't reinvent the wheel once more, just implement the standards.

ajconway 7y ago
How do you handle push notifications with XMPP? > How many Matrix servers are out there On a side note, that's not fair. Every project has to start somewhere and it might be difficult to gain traction. It doesn't mean that it has no chance of evolving into the greatest thing possible in its market, dwarfing once popular competition, simply because it didn't come first.
- Reventlov 7y ago
  > How do you handle push notifications with XMPP? XEP 0357, implemented in servers ( https://modules.prosody.im/mod_cloud_notify.html https://modules.prosody.im/mod_cloud_notify.html for prosody, for example), and implemented by clients ( https://github.com/siacs/Conversations/issues/1171 https://github.com/siacs/Conversations/issues/1171, for conversations for example). Conversations also uses XEP 0198 and XEP 0352 for battery optimization: https://conversations.im/#optimizations https://conversations.im/#optimizations