Drawbacks of P2P and a defense of Signal
changelog.complete.org
changelog.complete.org
Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now. But the capability would be there. That way, if x government chooses to go after Signal's servers, the availability of all the code needed to run a replacement is already available.
As it stands, we are placing a lot of trust in the Signal Foundation for communication (assuming we rely on the Signal app/service). I have no problem with a central server being used for communication if I can communicate data in a zero-trust way. But I want assurance that that server can be quickly and easily replaced in the event it goes down.
EDIT: I stand corrected. Server code is here: https://github.com/signalapp/Signal-Server Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
Last updated: 9 months ago
Unless I am missing something obvious in GitHub UI.
The whole literal point of the protocol is so that you don't have to trust the server, assuming you trust the client and protocol.
I feel like this misses the point of what Signal is. It's not just software, it is the network as well. The client is a client that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.
People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).
> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
This is actively discouraged: https://github.com/libresignal/libresignal/issues/37#issueco...
There's nothing there about preventing anyone from running a signal-compatible service/network and shipping a fork of their own client to connect to it, which is my original point.
In fact I’d say it’s actively encouraged to fork both the client and the server. What is not encouraged is just forking the client and using Signal’s servers.
“I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.“
That's because people have a reasonable assumption that a single actor (however good it is) should not have power over all of our communications. That's why we had federated networks in the first place (HTTP, SMTP, XMPP, DNS). Avoiding vendor lock-in is an important feature for most people.
° Let's gloss over the fact that all here is hyperbole, unless you use a single mechanism / medium for communicating with everyone.
A bad state of affairs is no reason to keep going in the wrong direction.
Agreed DNS might not be the best candidate for this. However DNSSEC validation within the LAN (eg. on your local router, not @Google/CloudFlare) mitigates a lot of risks associated, and a new secure backward-compatible protocol like the GNU Name System (yes that's a thing) may eventually overcome those risks entirely in clever ways.
There's literature and actual deployments on tying name resolution to public key discovery in location-addressed protocols (eg. .onion, .i2p..) and it makes entire sense in my view. If such concerns interest you, check out the latest GNS draft RFC: https://lsd.gnunet.org/lsd0001
Pretty much every way you look at DANE, it's a debacle.
Signal's research and protocol is already used in, well, basically each and every discussion/video platform. WhatsApp, Telegram, Skype, Facebook Messenger, Google Messages, Duo... so it's hard to see Signal becoming more ubiquitous. Seeing the app more will probably happen naturally when events happen (like the WhatsApp privacy change) to drive people towards more secure platforms, but honestly I don't really see a major shift anytime soon.
https://www.cryptofails.com/post/70546720222/telegrams-crypt...
Regarding Scuttlebutt (SSB), this isn't quite true. While IPFS requires a DHT, SSB's primary mode of updating content is via servers such as pubs and rooms, the DHT in SSB is optional and not the most common mode of updating content. In SSB you can and should choose the servers which you're connecting to, so in that sense it's closer to the federated model.
It's not entirely fair that the article equates "P2P" to "DHT", there are many ways you can do P2P connections, a DHT is only used for discovery. IP leakage is a problem in all these models (centralized, P2P, federated, etc): some computer somewhere will see your IP address, and you have to trust them not to do bad stuff with it.
For a comprehensive overview of privacy in DHTs and P2P, watch this talk: https://www.youtube.com/watch?v=nCCkwU4JPcY
I will agree that voip/video isn't there yet, tried it with some friends and none of us could get anything working. I did go out and set up a TURN server afterwards, but once a piece of tech fails as badly as element did for us the damage is done. E2EE could definitely be done better as well, but in another post on here I saw a comment detailing a bunch of clients (many of which were abandonware) that didn't support E2EE at all. That's going to kill mass adoption, since you have no idea how many people are on those zombie clients that you still need to support. I wonder if the Matrix API has a way to define versions for these purposes, to advertise the highest supported version by both the client and server?
I have it running on 4gb 8core arm sbc nowadays and i dont dare to federate. When somebody connects to a federated room with history and many users it explodes.
It seems future will be federated but with beefy servers.
Considering Matrix supposed to be the answer to decentralization... its mostly used on one main instance or in centralised silos like companies.
Every part of setting up a server that will federate/host repeats again and again that you need a TURN server (and they recommend coturn) - which is another 26,000 character config file - in order to do VOIP. If you've ever run or used a pbx before, STUN is needed 100% of the time for nat traversal between clients. Coturn even says it won't run if it's NAT'd (it will, but that's irrelevant to most people.)
This is the fourth concurrent tech trial of chat daemons, with rocket.chat and mattermost being a couple of the other ones that we're testing. synapse/element/matrix has the benefit of forced e2ee by my configuration. I don't know of any other matrix federated servers, so i haven't tried that yet, but an associate says it works on my configuration - which means it's not as big of a pig as i thought it was based on the outlandishly, comically large config file - where whitespace matters!
Mine only has around 100 lines without comments.
# cat /etc/matrix-synapse/homeserver.yaml|wc -l
1611
# cat /etc/matrix-synapse/homeserver.yaml| grep -v '^\s*#\|^$' | wc -l
101
The federation API on matrix is a little too chatty for my taste. But that in itself causes no problems. The problems start when a user on your homeserver joins a massive room on any other homeserver. Most commonly these are the bug rooms on matrix.org. Once someone joins one such room, synapse will start slowing down and taking tons of RAM. This has significantly improved in the last year, by huge leaps and bounds. It however does remain a memory hungry process.
VoIP / video on the other hand has been a success story for me. 1:1 calls run smoothly after installing a TURN server. Me and my users use the calling functionality multiple tines a day and don't seem to have any problems with it.
I use between some friends and family and I'm also connected to massive channels like the official "Element Android" and "Element Web/Desktop".
And it runs... just fine. The server can be a bit performance hungry but I also host plenty of other services on my VPS (email, HTTP server, Seafile, VPN, etc) and I never noticed any degradation in performance in any of them.
They have been making a lot of progress in improving the performance of the Synapse server and it is very usable now. And it is not difficult to configure at all, it's easier than configuring Prosody.
I would say that the bottleneck now is more about improving the UX and the Voip capabilities of the clients.
These days it's mostly fine. The database is about 15GB (including media), there are scripts around the net to clean it up (rooms you've left, etc). Joining big, federated rooms is ram-expensive with synapse, though you now can specify a maximum complexity on your server to prevent joining those. Other small federated rooms are completely fine to join, and don't cost much more than a local room (IMO, there's little point in hosting a non-federated matrix server).
I use yunohost to simplify deployment, though it has some limitations. I did give access to a few friends, but I feel like I cannot guarantee uptime even though it has been pretty good so far. Once profiles-as-rooms land, that might change, as a user could just hop on another server if mine is down.
I have about 20 users, with 5 of us being really active (but not much federation).
The computer is an Intel Kaby Lake i7 - really nothing special. I’ve never noticed crazy CPU usage.
Encryption UI is a mess. I have actively tried and failed to set up E2E encryption with at least one other technical user. Recommend disabling encryption unless you want non-technical users to abandon ship immediately.
Same here. A centralized app (like Signal) is more effective than distributed/decentralized approach. But what would happen if Signal would ever stop being benevolent?
Remember the days Google were "do no evil"?
https://www.reddit.com/r/technology/comments/kt91qk/comment/...
Their intention is good, but I fail to see how it ensures that Signal, the project or the management of the app, would never fall into bad hands. Promising such a thing is somewhere between naive and misleading.
You fork it.
Google killed it with groups 2.0 (1.0 was quite well done).
Same, what happens when your Matrix instance stops being benevolent? You switch.
The critiques of p2p identity leaking and big hungry servers are valid and I'm glad they are raised. As a Matrix user, I could respond to the first point that yes, it's a tradeoff depending on your threat model. I think that having a tractable identity is less bad than having one point of failure and moderation, on the broad social scale. If you are more concerned about very strong security now, you may decide differently. I think in the future, you could use an unfederated server of Matrix if you want something like Signal for sensitive connections. And yes, maybe pure p2p with no server nodes will never be viable for some use cases, with some threat models.
I do hope that in the future there will be an optimized Matrix server implementation in a faster language. (I'm saying Matrix, but of course my "loyalty" is ultimately more to the type of vision than some specific project.) I'm willing to cut some slack (pun unintended) to people having to iron out their big visions in an easier, more lenient language first. It's more important to have the features people want first.
As to the difficulty part, again, this is a legitimate concern, but I feel in HN comments and similar places it degenerated into a complete meme. All technology is "hard" for most/some people. I know older folks who drive to a clerk in a store to ask them to show how to do stuff on IPhone. There is always some greasing and other people having to tell you how to use it, not everything can be intuited. But you can simplify: point folks to a specific client (Element), which will point them to one server (Matrix.org). (Or, say, a random wallet like Ethereum does it?) I've done it with success with a bunch of "non-technical" people. No decisions needed on their part, but they could make them if they wanted to research (and not everyone has to want to!). It was no different in the era of email expansion and Outlook.
In the Jabber federation, we've had servers federating over tor onion services for about 8 years now, if that can be of interest to you (see prosody's mod_onions).
We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distributed systems that we already have!
Edit: for those who are interested in using XMPP in 2021, there is a good list of public servers available at https://list.jabber.at/ and a list of clients that support modern OMEMO end-to-end encryption at https://omemo.top/
In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion, I like to ask myself this question. How many people actually use the thing that someone is telling me is so much better for the world? If it's so good, why is nobody using it for practical things? Have they used it before and there's a decline, or is it a new up and comer and it just hasn't caught on?
I think just asking the question sparks a valuable train of thought.
They are not talking about "technical superiority" though, but about "alive and kicking" and "work together pretty decently" and you followed up with a question of daily volume as somehow being the indicator of the maturity of the technology itself.
There are multiple reasons for a lack in adoption, of course. Network effects, FOMO and walled gardens, financial might and power of dominating competitors to name a couple besides just the quality of the tech itself. And it doesn't help when many people off-handedly state the technology is not good, because it is not yet as broadly adopted as the centralized giants it is trying to be an alternative too :)
The 'why' you have here is a more open question and there's a lot in there. Companies trying to make money from it, users not having seen many real privacy implications on a wide scale, police presence being up and down etc. etc.
Based on some yearly port-scanning surveys [1], the developers of the Prosody XMPP server think there are over 50,000 servers running Prosody (out of a total of over 85,000 XMPP servers). There are a handful of large public servers and then what I imagine would be a very long tail of tiny private servers.
I'm not arguing in favor of these corporations. I'm a proponent of non-profit federated networks like the Jabber federation (based on XMPP protocol). Not that XMPP is better than ActivityPub/Matrix in all regards, but it has stable standards, rock-solid implementations with very good scaling stories, and there's a vibrant non-profit community working on:
- better, modern clients for chatting: Conversations, Dino.. - unified branding/UX across platforms with Snikket client/server distribution - social networking: Movim (web), salut-à-toi (multi-platform) - decentralized forging to replace github: salut-à-toi uses it for own development - onboarding people with prosody's mod_invite - federated chat over tor onion services with prosody's mod_onion
Matrix, SMTP and ActivityPub have other strong points going for them, but i could argue most of the Matrix criticism in the article does not apply to the Jabber ecosystem. Disclaimer: i'm a happy Jabber user and contributor to the https://joinjabber.org/ project (a new born in the ecosystem)
While being federated is a huge plus for me, it still needs to be a good and usable messenger on all other fronts. If I can't imagine my mother using it, you are doing something wrong.
I am not usually of the "software must be usable by a baby"-front, but for a messenger adoption is key, and unless I only talk to my nerd friends it needs to be both simple and at least up to task with Signal (videocalls, groups, easy to find contacts, ...)
If it’s anything more than open app >> fill in phone number or create account >> see list of people to chat with, it’s already dead in the water.
https://play.google.com/store/apps/details?id=im.quicksy.cli...
And I want to be able to recommend it. I just currently can't, this was the point of my comment.
It's already HARD enough to get them on Signal because they can't just click on the "Connect with Facebook" button. I got my mom on Signal and she actually converted other people to use it because it was not much harder than Whatsapp to set up.
XMPP nerver killed MSN back in the day's for the same reason...
first it automatically trust the devices but if you want you can improve it with manual verification :
"TLDR: Automatically trust all new devices of contacts that haven’t been verified before, and prompt for manual confirmation each time a verified contact adds a new device."
I mean, surely there's a decent XMPP web client out there you could use with OAuth.
Support for creating invitations from within the app was recently added to Conversations (sponsored by the Snikket project). I'm hoping to see more servers deploy this functionality in the coming year, and more clients implement support.
Snikket is built around the idea of invite-first for onboarding onto self-hosted servers. As the dev I may be biased, but I've onboarded many people seamlessly this way.
The article brings valid points that are not invented.
https://play.google.com/store/apps/details?id=im.quicksy.cli...
It's as easy to use and to automatically recognize contacts as Whatsapp and Signal but it's federated to XMPP.
And people who don't use Quicksy host service can register to be easily recognize as a contact :
> We charge a small fee to enter your Jabber ID and phone number into our directory. This cross financing allows us to make Quicksy completely free for its users. If you are a paying customer of the conversations.im hosting service, you can enter your number for free.
As stated on their home page, it's a fork of the Conversations (conversations.im) client with contact discovery which they're selling.
> Quicksy is a spin-off of the popular Jabber/XMPP client Conversations with automatic contact discovery.
So it's just a conversations.im client trying to make a buck with a contacts service based on what I can see. Edit: in context in case you didn't know, Matrix (at least via app.element.io -> vector.im) has a contact discovery service, and it already works with phone numbers and email addresses using a blind one-way lookup for privacy.
I'm not someone implementing XMPP but I remember reading articles about it back in the day and I recall hearing that the consensus that it's not a good protocol for mobile. Mobile being probably 95% of messaging traffic.
That means apple & google are effectively dictating how you can use TCP (i.e. not outside of HTTP and friends), and everything is now terrible.
Ok, but this is our reality. Windows has been the dominant desktop OS since 1995 or so (and MS-DOS was the one from 1985 until 1995 or so, from the same company).
Linux has been dominating the server space since about 2005 or so.
iOS and Android have dominated the mobile since about 2010.
I'm not holding my breath for any of these OSes disappearing from their niches before I die...
1) UE / ease of use for non-tech savvy users
2) a "killer feature" that gets people talking
While 1) is a no-brainer, 2) is a more difficult.
What does matrix offer to users other than "decentralization" (which is great for people on HN who like tinkering, but a usability drawback due to bootstrap time of joining a p2p network, and p2p in itself not offering a __security__ advantage[please ask to see the threat model when there are blanket claims that p2p is more secure]).
Signals claim to fame comes from actual subpoenae that returned no usable metadata. Matrix (so far) has never been tested in adversarial conditions[citation needed]. While matrix's e2ee is an often talked about feature, it is not part of most matrix-implementations. Only riot claims it does e2ee however the claims on voice security are vague. Not clear if p2p or multiparty voice are E2E encrypted. Also you can optionally encrypt text chat rooms (which means it's not the default and so it's either not used by non-tech savvy users and those who rely on it risk getting exposed due to the extra steps it takes).
I'm excited for decentralized technologies[3] but Riot is not in a state (yet) where I'd recommend it to exposed groups or individuals. So if neither e2ee is properly implemented, nor does it offer some radical new feature, nor is it actually more user-friendly - then why should anyone bother with it?
[1] compete = moderate attempt in getting a name for itself considering that Signal is stealing all the attention in comparison to all other "secure" messengers
[2] https://www.documentcloud.org/documents/3120046-Open-Whisper...
[3] cwtch: more bleeding edge than matrix, potentially buggy and certainly not ready for prime-time but they understand that: "your threat-model isn't my threat-model" https://docs.openprivacy.ca/cwtch-security-handbook/risk.htm...
Also a problem is iOS clients. Developing on iOS requires lock-in into the Apple ecosystem and most XMPP folks are free-software people so nobody will bother to buy Apple hardware/software specifically to develop for their closed ecosystem (i.e. unpaid labor for a multi-billion corporation), although i'm sure a lot of folks would be happy to do just that if that was sponsored work (donations, grants).
On Android, Conversations (or its forks Quicksy/Snikket) is the best. ChatSecure on iOS has been buggy for years (every time i tried with someone with an iPhone), but nowadays Siskin appears to be a good iOS client, though i haven't had the hardware/system to try it myself.
I didn't downvote but your comment doesn't help me because it's what I call "generic & enthusiastic evangelism" that does not actually engage any of the concrete arguments in the blog post. An example of another comment that does try to address the author's issues is the one from arathorn[1] and I hope that one gets upvoted to more visibility.
As an example of a concrete point you didn't engage with, he worries about the reliability scenario of sending a critical message such as "my car broke down".
You cite a link of XMPP servers. But here's another list of servers where many are colored pink (they're no longer online): https://www.jabberes.org/servers/
How does the average person curate your list and avoid choosing a server that will be offline pink in the future? Non-techie people don't want to keep switching servers because somebody quits their hobby of running a XMPP server.
That's an example of why directing friends & family towards Signal is less of a cognitive burden.
The author also mentions ease of voice & video calls on Signal. The cheerleading "XMPP is alive and kicking" doesn't address that either.
I'm sorry my post has come across that way. I simply wanted to point out that framing the argument as "Matrix vs $PROPRIETARY_SERVICE" is unhelpful at best.
As an actual user of XMPP who has managed to get (some) of my contacts to join me in this brave old world of federation, I get frustrated when the conversation turns to "Matrix vs $CENTRALIZED_SERVICE_OF_THE_DAY" -- it's a false dichotomy that ignores that fact that 20 years later XMPP is still here and still hasn't died. IRC and SMTP are the only other standards for messaging that can claim that kind of longevity.
Of course XMPP is not perfect. But it's what we have to work with, and throwing our hands up in defeat and crawling back to the centralized platforms that keep letting us down is not the way forward.
One can use email and have an address at Google and one at work, and know these data points for a friend. One can use a phone and have multiple service providers (in some countries multiple sims for costs, in others legacy landlines.) One can use WhatsApp, Signal or Slack and then you need to synchronize on an entirely different backup service. None of them have the POTS guarantee and for the most part we (at least in my age demographic) don't even trust the POTS service with non-redundant numbers.
This happened to gmail recently, too, and my realtor couldn't send me contracts during a bidding war. In the case of gmail, it was an accidental reduction of provisioning to an internal service (perhaps easy to predict if you ignore the enormous complexity of the googleverse). In the case of Signal, it was a result of a scaling suddenly and faster than they could be expected to predict (perhaps easy to predict, but not a certainty; a risk in any case for a small operation like Signal).
> server implementation
In the Jabber ecosystem, there's a bunch of servers. Prosody and ejabberd are the most popular ones with easy configuration and extensibility, high reliability, support of all modern features (XMPP Compliance Suite 202X), and packaging for all distros. There's a lot more servers, but they may not be as reliable/complete.
> use matrix.org (...) or (...) will it be up (...) ?
There is no equivalent in the Jabber ecosystem, on purpose. Nobody wants to centralize all accounts, or wants to advertise services which may disappear some day. Jabber services, like web hosting and emails, is meant to be provided by hosting providers which will still be here decades from now. As with any protocol, you should never trust a provider of a single service (who doesn't deal with other protocols), unless they're the person developing this service and you want to support them. More often than not, these single services hosts are run by inexperienced volunteers who cannot guarantee they'll still have time and motivation to maintain the services years from now.
Some non-profits have been serving Jabber accounts for their members for more than a decade, like JabberFR here in France since at least 2005. And these "small" servers (JabberFR has ~700 parallel users and 2-3K servers federated with) take very limited resources and have much better uptime than most commercial messengers.
> Voice and video
This has been a long problem in the Jabber ecosystem because little people were working on it. Nowadays, 1-on-1 audio/video works perfectly across Conversations (mobile) and Gajim (desktop) and group AV works perfectly with Jitsi.
> Matrix is so hard to set up on a server
Jabber is really easy to setup on any server.
> Encryption isn’t mandatory in Matrix
Encryption isn't mandatory across the Jabber ecosystem, though some clients strongly encourage and facilitate it. This is the only criticism of matrix in this blogpost that equally applies to Jabber.
> How does the average person curate your list and avoid choosing a server that will be offline pink in the future?
That's a fair question. Registering with a hosting cooperative (not private corporation) which has a good track record is a good start. This is one of the reason we started the joinjabber.org project. Though we don't have a lot of servers recommended there just yet, we intend to curate services according to public criteria in the future.
> directing friends & family towards Signal is less of a cognitive burden
Not in my experience. This leads to questions like how can i talk to someone who doesn't have a phone number (you can't). Why is the service not working sometimes (smaller hosts have better uptimes). Why am i receiving phone calls from weirdos who took it from a groupchat i joined, i thought signal stood up for privacy. And hypothetically, in the future: why is Signal actively cooperating with law enforcement in my country. Why was Signal sold to a data-mining private corporation. Why is Signal going bankrupt and closing all services and where can i go...
I'd much rather take 5 minutes to explain to someone that Jabber is like email and they need to find a trustworthy, reliable provider, than spend hours and hours dealing with the mess and pain a centralized approach like Signal creates. Source: most of my friends and relatives are on Jabber; some have some moderate complaints about UX but it "just works".
When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most of my friends and family who were kind enough to try it out. Apparently Quicksy is free in the Google Play Store which is good news because nobody was willing to pay 2.50 EUR for Conversations and installing F-Droid just to install another app was quite a hurdle.
Is it? (genuinely curious) Can't one see the matrix server-server state synchronization protocol as a transport layer for MAM archives? And pubsub nodes in XMPP are very matrix-room-like. This could be an XMPP extension allowing to multi-home pubsub nodes.
Also, there are recent matrix proposals [*] for representing several things (groups and user profiles) as rooms. Given the analogy room=pubsub, the user-profile-as-room seems to be the same thing as XMPP's PEP (used to share personal data, like public keys or avatar). And the group-as-room would be the MIX proposal.
[*] https://github.com/matrix-org/matrix-doc/blob/matthew/msc177...
Indeed. For sure XMPP has ugly corners (disclaimer I never implemented anything, mostly read some XEPs). I believe parts which are quite clean are the pub/sub part and the message archive (MAM). Afaik the current group chat extension (MUC) isn't so great (once you try to add history multi-device) and some people are trying to refactor it on top of pubsub (MIX) but it's not very active.
The matrix team clearly had precise ideas about the right way to do federated group chat and in fact (again afaik, my matrix knowledge is dated) their "rooms" seem to be quite flexible by not being completely tied to a particular server (several servers participate in hosting a room). Imho matrix has an edge in designing this from scratch and already knowing what the hard parts are from the beginning and i hope the good ideas will come over to XMPP. Perhaps some day an XMPP server will support matrix, making more clients available to the network (well integrated clients on every plateform is the real hard part for every distributed network).
At least an email to the user's @Facebook email address gets picked up in messenger.
Back in 2016 I came across a computer science paper where the author had studied the decentralization vs. centralization phenomenon in various cases (not just in IT but also in real-life social networks, economic dependency graphs etc.) and concluded that every man-made decentralized system will eventually exhibit centralization to some degree as it will develop nodes that have orders of magnitude more edges than the average node. It seems to be a very natural phenomenon. I wish I remembered the author or the title…
As another commenter has pointed out, Delta.chat shows just how closely an email client can mimic the chat/IM interface.
I ran a medium-small sized XMPP community for many years, and eventually the community abandoned it and went back to IRC because it had better client/bot support. Matrix has a really good solution for end to end encrypted group chat, so I haven't seriously looked back at XMPP since then. They were the first ones with a decent solution to the most important feature I needed in decentralized group messaging, so they won IMO.
I tried a couple times to build out my own clients/bots etc for XMPP, and it just seemed way overly complex. I had to bundle something like 30 megs of jar files for a simple hello world app.
Also some silly things like ejabberd refusing to hash passwords in their user database because they were "already encrypted with SSL". It was all just a frustrating mess, and a security nightmare.
Matrix, with Element, has a pretty web frontend that does encrypted messaging right. If XMPP has anything like that, please do let me know, but every time I've glanced back at it, it seems stuck in the stoneage of messaging apps, still working on getting a committee together to form the standards for even the most basic functionality that everything else had 10 years earlier.
It's basically the same encryption scheme as Jabber/XMPP uses with OMEMO. The two were developed around the same time. On Jabber existing rooms need to be set to "members only" and "non-anonymous" for encrypted groupchat to take place because Jabber multi-user chats enable using nicknames (only the MUC operators know your address) which prevents clients from querying each other's key.
> I had to bundle something like 30 megs of jar files for a simple hello world app.
That sounds horrible. There's pretty good XMPP libraries around nowadays, like slixmpp if python is your thing. There's also a WIP Rust xmpp library if you'd rather.
> Also some silly things like ejabberd refusing to hash passwords
That sounds creepy. However, prosody does that very well though. And it seems ejabberd supports SCRAM authentication since 2007?
> Matrix, with Element (...) If XMPP has anything like that
ConverseJS is a web-based Jabber/XMPP client that does encrypted groupchat. It's supported by other clients as well (such as Conversations on Android). Movim, the more popular Jabber web client (because it has social features) does not support OMEMO yet unfortunately.
ConverseJS may not be as user-friendly as Element though because they don't have (yet?) the $$$$$$ of VC/government money matrix has.
> still working on getting a committee together to form the standards
There is a bureaucratic tendency around the XMPP Standards Foundation, because standardization is very important to avoid lock-in. However client devs have pushed features before/meanwhile publishing specifications and bureaucracy does not seem to be a concern for (some?) devs in practice.
Matrix on this topic and their view
There are a bunch of XMPP servers running on Tor hidden services:
* https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...
... but the article talks about Matrix instead for some reason.
> Just for the hell of it: Anonymity is fundamentally about removing context. You can't provide anonymity you can only provide protocols that endeavour to remove context. Attacks on anonymity system always come down to injecting or deriving context.
> In an adversarial environment (just so we are all on the same page, life is an adversarial environment), there are few limitations on the kinds of context attackers are allowed to inject or derive context from.
> No anonymity system is absolute because there is always context. The majority of my research in this space centers around the context that people add on top of robust protocols that ultimately undermine them. I'm interested in practical failures, not theoretical restrictions.
> Privacy will always been an active choice, not a passive tool. That doesn't make it impossible or out of reach or "dead", it makes it a fight worth fighting.
https://twitter.com/SarahJamieLewis/status/12737436308013711...
https://twitter.com/SarahJamieLewis Sarah Jamie Lewis @SarahJamieLewis Executive Director @OpenPriv
Anonymity hasn't the same requirements as secrecy does.
The greatest advantage Signal has is probably doing same-day updates for all clients while being dead simple to use well. A decentralized protocol could achieve these things, but none have yet. Still I hope someday soon we can have everything be decentralized, but like the blog post says, we can't let the perfect be the enemy of the good.
Federated, not decentralized. Decentralized is peer2peer like torrents. Federated is like email where there are little fiefdoms like Gmail, yahoo, or self-hosted.
No it doesn’t. Gmail is a centralized instance of a federated network.
You can have a federated node that becomes so popular that it’s basically centralized.
This federated/decentralized distinction is pretty common.
You’re dwelling on literal definitions but there are more semantic differences those words have picked up in the communities involved.
For a long time, federated architecture was seen as special case of decentralized, for example in designing stuff for internal use. It still makes sense in that context.
In the context of larger external facing systems, I've found it useful to think of federated as "partly decentralized", and "decentralized" is short-hand for "fully decentralized".
1. Open source. 2. Has verifiable builds (just being open source isn't enough). 3. Uses end to end encryption.
You need all three of those to get what you want. Also you need to spend a ton of time building Signal from source and auditing it, which I doubt you're going to bother with but at least in theory it is possible.
They can't, provided you verify the (reproducible) builds you download from the app store and check your verification codes.
Besides, it would be rather difficult for Signal to target just you and hand-deliver a custom build to you – Apple/Google would have to in on this, too. And if you use a Play Store alternative like the Aurora Store with a random Google account, this wouldn't work, either.
> Why should I trust someone to route my messages?
Unless you want to put the cables in the ground yourself and run the entire internet's infrastructure on your own, you'll always have to trust someone.
If you make a direct connection to other users, they see your IP address. So use Tor or a VPN.
Many P2P lookup systems assign identifiers for routing etc. So assign ephemeral ones for anything that doesn't need a persistent one, and make sure persistent ones aren't suitable for correlation, either by not using the same identifier for multiple services by the same person, or by using the same identifier for multiple services operated by a large number of unrelated people, or both.
Encouraging users to use a VPN can be as simple as bundling the WireGuard installer with your software and providing a list of recommended non-shady VPN providers.
This makes things less complicated for the user, because they benefit from having a VPN whether they use your software or not (to hide their current IP address from any centralized services they still use), but now they have someone they trust providing a vetted selection of them to choose from. And on top of that it gives a free software developer the opportunity to fund some development through the use of affiliate links.
Using a VPN or Tor is not a viable option for the average person.
Letting users select their own VPN before using your service is too much friction. The advantage of Tor is that it's run by multiple parties and does not need any interactive setup.
How much did you need to understand about TCP/IP when you got AOL? Very little.
And what happened when you got online? You could communicate online, suddenly reaching millions and then billions of humans. So learning just a little bit about IP (let's be real, you didn't need to know shit about TCP)
Compare that to a VPN or Tor. What do you need to understand to use it, and what is the payoff for knowing it? It's nowhere near the same situation as IP and the beginning of consumer internet.
TLS was not in the original email RFC. Such a high percentage of email servers use it now that some have started refusing to communicate with ones that don't. And long before 100.0% of email servers support TLS, you can still use it whenever it's supported by the servers of the sender and recipient.
The DNS RFCs contain a specification for zone transfers, i.e. requesting all the DNS records in the zone instead of any given one. Some people don't like the idea of anybody being able to download their entire zone, and it was always a silly way to sync zones between DNS servers as opposed to using e.g. rsync, so most DNS servers on the internet refuse to do it and a lot of DNS server software doesn't even implement it. But the people still using it internally for whatever silly reason can carry on doing so indefinitely without hurting anybody else.
Nobody cares about the legacy cruft that nobody they care about uses. What having central control gets you is the ability to decree from the tower that something some people are still using shall be removed for everyone everywhere. That can be more of a bug than a feature.
The biggest actual problem with protocol ossification is stupid network middleboxes that manipulate or drop traffic and then break on protocol changes they don't understand. The way to fix this is for future protocols to be encrypted so the middleboxes can't mess with it.
It even mentions Tor.
You seem to trying to argue something different than what the article is actually about.
If they aren't impossible to solve then why should we not just solve them instead of abandoning decentralization?
Bisq (p2p exchange) does the same thing.
Basically it works like this:
> Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.
Quicksy offer EXACTLY the same functionalities but it's federated and standardized, based on XMPP : you can discuss with people that are not using Quicksy and its services, people outside Quicksy even can link their address to their phone to make it automatically recognize as contacts using quicksy/XMPP : https://quicksy.im/#get-listed
And instead of Matrix, Quicksy IT IS THERE YET :
https://play.google.com/store/apps/details?id=im.quicksy.cli...
To repeat my question, how are apps that require a phone number scamming users?
…and leak my message content, IP address and social network to everyone who cares to look? You're making a very broad claim here and implicitly assume a very specific threat model. I can come up with dozens of other threat models that are more relevant to me and everyone I know and that completely invalidate your statement.
Would you care detailing this?
- Private conversations are E2EE by default now, group chats can be E2EE.
- IP addresses are not leaked except when videoconferencing. This is also the case on Signal, mind you, unless you opt-in to use their proxy in the settings.
- Social networks? Care to explain that?
- Who is everyone? Your server admin? Your ISP? Someone MITMing your HTTPS connections?
I do not doubt the rest of your post, but the above criticism is just unfair, given what I know of the Matrix protocol. Of course, I could be mistaken.
If it can't fit on raspberry pi it's useless.
I was hoping for Rust, and I think there is a 3rd-party Rust server, but anything's better than Python. Node.js would probably be better than Python.
I'm hopeful it will get there somewhere, but I hestitate to recommend it while "easy to get working without issues" is a bar that it doesn't yet reach.
/aside: this is a curious comment in their readme:
"A PostgreSQL database engine, which will perform better than SQLite with many users and/or larger rooms"
But for something like a social network, performance isn't something they care about. They care about being able to develop and roll out new features as fast as possible. The overhead of working in a language makes things hard and/or has poor tooling is far greater than the increased server cost of working in something like Python (or, as much as I hate to admit it, Node).
(note, that I'm not talking about the client side here. developers should serve their users and a slow fronted is bad for users. a slow backend, however, is not something users care about)
And since we're specifically talking about an open source project here, look at the difference in community contributions between any two equally popular projects where one is written in something ridiculous like C++ and the other in JavaScript.
Even Go and Rust, which are as close to modern as it gets in the world of compiled languages, are still decades behind Java, Python and Node in features, tooling and support. So until those catch up, anything that doesn't need performance above all else is probably going to stick to more friendly languages and not lose sleep about wasted CPU cycles - after all, we built computers specifically to simplify our work and that's exactly what these languages are doing.
Millions of people use Matrix. It has been adopted by the French civil service, several German states, and the German armed forces. In a previous post I saw someone saying that American Airlines was looking at adopting Matrix for their employees.
I assure you that whether or not the reference Matrix server runs well on a raspberry pi did not factor into the decision making process that these organizations used when they picked Matrix.
I've found that loading the larger rooms from the matrix.org network can cause a bit of lag for the few dozen or so users on my servers but once the rooms have synced up that issue goes away.
I don't administer the servers personally so I don't know exactly what the issue is but I have a feeling it's due to the limited ram that is provisioned to the VMs running the instances of synapse as there are many other VMs running on that same laptop.
If the instances of Synapse were the only things running on the laptop and they had 12gb of ram each (1/3 the total 32gb limit of the laptop) I would imagine that this issue would go away.
So not like email where you can have tiny server and still be part if the network.
I have an old laptop running a bunch of different services, three of which are matrix servers. The matrix servers generally run fine with the modest amount of ram provisioned to them (2-4GB IIRC) with the exception of hiccups that occur when a user joins large federated rooms (we're talking several thousand users) and these hiccups only last for a few seconds and until the room has finished syncing to my server. The hiccups manifest as "Unable to connect to server" messages on clients which only delays messages from being transmitted to the server by a few seconds.
From my understanding once a single user has joined these rooms and triggered the server side sync these hiccups will not happen again once another user on my server joins the same rooms as the data is already synced on the server. Furthermore there are relatively few rooms that have the number of users necessary (1000s) to trigger the issue one time join issue.
To remedy this issue and for general network reorganization purposes I intend to migrate non-synapse VMs off of the laptop and onto other hardware and then I would simply delegate the old laptop for the matrix servers and scale the three VMs to give them 1/3 of the available ram whether they need it or not. I mispoke last night when I said 12gb by the way, as the laptop only holds 32gb ram so the available ram could be (32 - (ram for hypervisor) / 3)
To bring it all back to the thing I care most about which is the over all cost, if the laptop cost $300USD and I run 3 servers on it my hardware cost per server is $100 which I consider to be trivial. This is 20 cups of fancy coffee and more importantly many hobbyists already have a spare laptop sitting around or can find one for quite an affordable price.
I hope this clarifies my comment.
Please don't repeat falsehoods like this. The average person can not run anything because software is black magic to them. If you meant the average knowledgeable computer engineer (or similar, as opposed to a large org), then you are simply wrong.
I'm running a Synapse instance for ~25 people (friends and family). We are federated and joined to many large rooms. Synapse is using about 400-600M memory (RSS, varies depending on circumstances) and about 8-10% CPU. This is all on a 2 core Hetzner VPS which costs less than 20 USD per month.
You accuse the parent commenter of making a falsehood, but then you go on to confirm their statement as true.
To be perfectly clear, the above was the original statement I was referring to and it is completely false.
It’s also not going to remain true over time.
But it’s not a false characterization in practical terms for most people.
In what sense is it then true that you have to be a large organization and have a powerful machine to be able to run it?
Here is a quote:
“speaking as the project lead for Matrix.
1. It's true that Synapse can use a lot of RAM.”
Do you really think "but enterprise organizations don't mind running it" is a great argument? By that measure, JIRA is also perfect software :D
I know plenty of places running their own Matrix servers, and while it's certainly not unusable (proven by the fact that they keep running it), it's a common refrain among their admins that Synapse is one of the more annoying pieces of software they run in their infrastructure. That's not "bikeshedding", but operational experience, which has an impact on if it's recommended or not. See also the ... varying ... quality of matrix's bridges to other ecosystems, even the ones that are provided officially by the Matrix project. So yes, there are actual issues with Synapse performance - "rewrite it in Rust!!111" is of course not necessarily the correct response :D
The fact that it doesn't run on your toaster is probably a feature, not a bug. To get it running on a Pi, even if written in a compiled language, things would have to be stripped down, making the overall software worse - a for what reason?
Running a Matrix server on a Pi in your closet is about the worst thing you can do. It's slow, unstable, has zero redundancy, needs constant maintenance, is physically in your home, on a residential connection.... If the point were for users to run this themselves, something like a local NAS (Synology has 1-click apps, I believe) would be the lowest-end reasonable option, but the whole idea of running your own Matrix server at home is insane! At the very least, it should have basic redundancy for uplink, data and power, which are already near-impossible to achieve at home.
And why should servers hosted by individuals? That would be horribly wasteful and inefficient, as well as raising the bar for users. I'll guarantee you that anyone who has enough skill and experience running and maintaining servers will have more than just a Pi available to them and anyone who doesn't have that experience should really not be running such an important service themselves.
1. It's true that Synapse can use a lot of RAM.
- The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released on Wednesday: https://github.com/matrix-org/synapse/issues/8622 is interesting reading on the details.
- Another cause is that by default we cache a lot of data in RAM in order to avoid hammering the DB. Currently you have to manually tune the size of that cache, which should be done automatically - we're hoping to get to this shortly.
- The other main cause is that the resource requirements depends on the complexity of the rooms its users participate in, not the number of users on the server. So a single user server can use serious RAM if that one user goes and joins a bunch of busy rooms with hundreds of thousands of users in them. This can be surprising to sysadmins, and we haven't figured out a good way of solving it other than just keeping making Synapse go faster.
- Finally, even though we're continuing to polish Synapse hard, we're also working on Dendrite, which uses roughly 5x less RAM than Synapse (thanks to relying on the DB for caching, using a smarter DB schema; passing all strings around as enums called NIDs, and Go's GC being smarter than Python's). For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users. It's still beta, but progressing fast.
2. In terms of choosing a Matrix server: "Well, you could just tell a person to use matrix.org. But then it spent a good portion of last year unable to federate with other popular nodes due to Synapse limitations." - yes, at the beginning of 2020 we hit a performance ceiling on Synapse on matrix.org which caused federation to fall behind during heavy traffic. *So we fixed it*. https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca... has the details. Meanwhile, more and more other folks are spinning up reliable Matrix providing services.
3. In terms of "Voice and video calling are not there yet in Matrix", again: we've been working our asses off to fix this. Since September we've had a dedicated fulltime VoIP team going through reworking 1:1 VoIP, implementing the work at https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... This has been landing over the last few weeks (although there's still some stuff left), but it should already be noticeably more robust. Meanwhile, integration to Jitsi for video conferencing has also improved a bunch - we're counting on it for running FOSDEM next weekend, after all. In terms of NAT: yes, you have to correctly set up a TURN server. We're building https://github.com/matrix-org/voip-tester to help folks test that they've got it right.
4. "Matrix is so hard to set up on a server that there is matrix-docker-ansible-deploy". This is bogus, imo. The ansible project is useful if you want to quickly run tonnes of bridges without understanding how to admin them, but for a typical Matrix server you should be able to `pip install matrix-synapse` and off you go. It's a fair point that Synapse doesn't yet ship with an admin tool, just an admin API, but there are folks filling this gap (https://github.com/Awesome-Technologies/synapse-admin is good).
5. "Encryption isn’t mandatory in Matrix". This is because, unlike Signal, Matrix supports public chatrooms. It makes *NO* sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world. All it would do is waste significant CPU on the clients, and hit up against resource limits given how large public chatrooms can get. Meanwhile, all private conversations are E2EE by default, assuming your client supports E2EE.
TL;DR: It feels like we're being judged on Matrix as it was in early 2020, ignoring all the sprinting we've been doing throughout the last year to address these criticisms, so it's all rather frustrating.
That's impressive, congrats!
I hear your frustration, and I think only time can solve this problem, and it does eventually. It's the same with Signal and the initially poor user experience.
> It makes NO sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world.
Even if you don't want encryption, authentication is still good to have, so quick question: who authenticates messages when you deactivate E2EE in Matrix? In the case of a public room hosted on server S, A sends a message M1, then sends another M2. Assuming that S is not actively MITM until after the first message (so any initial key exchange can happen), can I be sure that the second message will not be tampered with?
IIUC a Signal group where a client would then broadcast all messages to the world would still provide such a guarantee. Is that the case as well for Matrix?
https://www.troopmessenger.com/blogs/mattermost-vs-matrix
That's a year old, so Google isn't doing y'all a service by highlighting that as it's insta-hit, we need something updated out there for 2021 for Google to latch onto.
I've created a Mattermost account for Rocky stuff and honestly, as a casual I can't tell why I'd want one vs. the other, they seem pretty much the same to me (even the UI is kinda the same). Matrix touts a lot of extra privacy stuff I think, that's about it...
$0.02 from the peanut gallery! :) I'm just using web clients and not the mobile clients (per my preference for this stuff) and use app.element.io as a comparison.
In fact, as I said in the post, I use Matrix, I love Matrix, I evangelize Matrix (especially to Discord people), it has made a lot of strides lately. I had a previous post on distributed offline-capable IMs at https://changelog.complete.org/archives/10205-roundup-of-sec... and I got so much feedback to "don't let people use Signal, switch to Matrix!" that I specifically was addressing Matrix as a Signal replacement in the post. (I regret it wasn't super clear that's what I was doing.)
I'm going to address your points in a sort of different order, starting with:
#5, encryption. The benefit to Signal here is that encryption is NOT optional. A user just knows everything is going to be encrypted. 1-to-1 chatting, group chats ("rooms" to Matrix), voice and video calling, attachments, EVERYTHING is E2E encryption and user error can't result in things being sent in plaintext.
Now as you say there are reasons that, say, #fx-desktop-community:mozilla.org with its 1100 users shouldn't be using E2EE. However, when talking about Matrix *as a Signal replacement*, the fact that E2E is only default but not mandatory for 1-to-1 chats, and optional but not default for multi-user chats (in Element), this makes it a lot easier for non-tech-savvy end users to goof and send messages in plaintext. A secure replacement for Signal needs to not have that option. Perhaps a "secure everything" mode in Element would help.
2. Fundamentally, there is a deeper issue here: for every Matrix user, there exists at least one, and possibly more, single points of failure. As far as I know, Synapse itself isn't clusterable, so for every Matrix homeserver, the failure of, say, a single CPU will render everyone on that server unable to communicate. I say "possibly more" because many people probably will run a singleton PostgreSQL instance also, though PostgreSQL can be clustered. Or even an upgrade to Synapse there would take people offline, etc.
For me to be able to recommend an IM to people, it must pass the "I can rely on this thing to get help if my car breaks down at night" test. Right now, Matrix doesn't give me that level of comfort. Yes, it's getting better. Yes, various hosting options exist. But still, if the homeserver you're using has a bad CPU or Synapse OOMs it or whatever, your messages aren't going through in a timely manner.
3. I am glad to hear that voice and video calling are getting so close. However, I want to still add that having two different VOIP systems -- one that can handle precisely 2 participants and another that can handle more -- is jarring for end users and admins alike. People are used to being able to tap "add participant" to their calls and this is a UX issue for people coming from other IM systems.
1. I'm glad to hear these RAM issues are getting better. I've spent a fair bit of time tuning that cache parameter, from its default of 0.5 down to 0.2 (which resulted in drastically unacceptable performance) up to the other recommendation of 2.0 (which still resulted in OOMs). I am in some large Debian, Firefox, and Matrix rooms, with over a thousand participants each -- though some of those, at least, are gated from IRC where such a scale is a non-issue.
I've been following Dendrite's "are we Synapse yet?" page with interest and excitement. I am looking forward to it being ready to use! But as I stated in my post, and as you are surely aware, it's not there yet, at least based on the "are we Synapse yet?" page.
4. It's not actually that simple. A person is most likely going to want at LEAST Synapse and Element Web. Most are probably also going to need coturn, Dimension, Jitsi, synapse-admin, and maybe an identity/directory server. The downloading of the software is the easy bit. The hard bit is getting all the bits talking to each other properly, with various JSON config files, keys, DNS entries, SSL certs, well-known files, ports, etc.
I set up my own Matrix server due to difficulties with the integrations at t2bot, some limitations in the IRC bridge I had to work around, etc.
Also to those wondering why Matrix and not XMPP: I used to run ejabberd and an XMPP service. XMPP has (or at least, HAD) a real issue when being used with multiple clients - delivering messages to the wrong place, not syncing history, etc. Matrix is far better with those things. Also Jingle in XMPP land barely ever worked, last I checked.
An aside: I try not to comment on non-federated corporate-control sites (of which HN is an example), but hopefully if you reply I'll get an email or something. You are also welcome to engage me on my blog or on Mastodon, where I first surfaced many of these ideas (and did tag the Matrix Mastodon account). Or email me.
Once again, thanks for what you do. Matrix is great for many use cases and will be great for more in the future. But I want to be clear-eyed about how it compares to Signal for the secure IM use case, today.
Signal is having technical difficulties January 15, 2021 (comments) Signal (business model: "Uber for texting") falls over. Most communications protocols are federated, and would survive one company's servers eating dirt, but Signal's owner/operator has decided this would degrade the user experience, presumably worse than the entire service shitting the bed out loud. Hackernews assumes that Signal is incapable of paying its hosting fees, and comes to the rescue by sending their money to a company that can't spin up cloud nodes fast enough to serve text messages. Other Hackernews bemoan the fact that once again they look like idiots, since they just conned half their friends and family into signing up for this mess.
Just dismissing it as "smells funny" is not a valid criticism.
But you can't verify that the open-source matches what's on the Play Store, you can't link to the official server with your own build, and you can't run your own because the server is no longer open source. (Last released a year ago)
According to their blog, builds are reproducible[0]. Am I missing anything?
> you can't link to the official server with your own build
Why not? (I know Moxie discouraged publishing custom builds while linking them against the official Signal server but this is not the same thing.)
Signal started of with not ONLY privacy in mind. In the beginning the app required even Google Play Services, which was dropped because of pushback from the community. It seems that his experience in sillicion valley startups, also reflects on how Signal manages growth and thinks about user adoption of their product. On top of that, they try to apply as much privacy as possible. If they would have started the other way around, they wouldn't have gotten so far. A certain spirit seems to be necessary to give privacy to the masses.
Next to that, they are paving the way to no longer require phone numbers: https://signal.org/blog/signal-pins/
Wasn’t it Google that wanted to make all information available on the web through their site? This is almost as bad as censorship.