141–150 of 169 posts
That said I do believe some of our XMPP customers are starting to look around and ask for REST/Websocket based APIs as their new dev team hires look to reinvent the wheel ;)
Seriously speaking though - I think XMPP missed the boat as far as messaging goes. Smart phone apps took everyone unawares and XMPP didn't move fast enough to provide a solution for low power devices on high latency networks.
That said I wonder if there is a future in which XMPP does prove to be a compelling solution. I wouldn't put money on it, but even today a full duplex API which is highly secure, async and which offers schema enforced validation of your messages sounds pretty damn compelling. That said there is a lot of progress with things like STOMP, RabbitMQ etc. providing the pieces necessary to replace XMPP.
It's a pity since XMPP makes it so damn easy to build reliable, realtime apps.
> A single decision by Moxie or a single court order in some country can make Signal unavailable to a large part of its user base. I think the solution here would be a "lightweight" federation of 3 or 4 entities following a common charter and covering a wide geographical area. If one drops out for some reason, the others will still ensure the service remains alive.
Then it is a single court order and 3 people agreeing on the same decision which is quite easy to make when it has to made at gunpoint. The actual solution has been known for ages: decentralization, federation, peer-to-peer. pretty much what the internet was designed to be.
Not if the 3 entities reside in different countries/jurisdictions.
> decentralization, federation, peer-to-peer. pretty much what the internet was designed to be.
While I agree with you from the theoretical standpoint, it's been already shown that neither users nor providers care about that. A federation is not by any means easy to maintain (just look at the amount of work spent in keeping e-mail relatively free from spam and usable). So, either the federation in question is small enough that you can keep it under control or you're better off researching a fully decentralized system that is resilient to all the problems all other services have (doesn't sound easy to me).
People who care more about convenience than freedom and privacy can and do use Skype, iMessage, and Snapchat. If you give up freedom and privacy to make a more convenient client, you're not improving the freedom and privacy situation, you're just making more of the miserable proprietary software that we're trying to get away from. If it's not free software, you have neither freedom nor privacy. If it's not decentrali…
Except that messaging services are useless if the people you want to talk to don't use them. If all the people you want to talk to share your prioritization of freedom & privacy above everything else, then you're probably ok using a federated, self-run XMPP style messaging system. Unfortunately, for the vast majority of people, that just isn't the case. I would love it if I could use XMPP-based services to talk to ev…
This applies to centralised/proprietary systems as well, including those 8 walled gardens that you use.
When Slack was created, nobody was using it. When Signal came out, nobody was using it. Same with Telegram, Skype, Twitter and all the other centralised/proprietary systems.
Some of those did manage to gain enough users for positive network effects to kick in, so "nobody uses it" isn't specific to FOSS/decentralised/federated systems, it applies to messaging systems in general. The fact that so many messaging systems keep being created, and so many users hop from one to another, shows that it's not a particularly strong argument either.
The real problems for systems like XMPP are the levels of investment required in marketing, UI design, etc. to compete with the proprietary systems.
I think there is still place for an end to end encrypted Jabber app with an option to self host the server. This would avoid the single point of failure issue that Signal has (Signal servers being blocked in certain countries).
Earlier quoted context omitted.
Signal requires users' phone numbers. True for Signal. XMPP is using JIDs which are functionally comparable to email addresses, and similarly anonymous (or not). Is there a way to run your own Signal server? The Signal client is open source, the server mostly so. You could create your own semi-Signal community, but it would not be able to talk to official-Signal users. XMPP is designed for federation by default, and…
Phone numbers are not always anonymous. In India and I am sure some other countries as well, you have to give a photograph and a government ID to get a SIM card. And that is why I am hesitant to use Signal: I want to talk to you but I am not sure if I should give you my number?
Also, in some countries like the US, you can buy 'burner' phones without any need for identification--no contract, no ID.
Earlier quoted context omitted.
But even if Moxie does something weird or some country breaks Signal. You and your contacts can easier switch to another system. While when your XMPP server admin does something weird or a country breaks it you are locked in. For Signal you use an ID which is not owned by Signal. So for Signal and alike the decentralisation doesn't come from the service but from your own social graph which is your phone book on your…
Is mobile number portability a thing in every country? I suspect that relying on IDs owned by another system can have its drawbacks. Maybe it's not likely that an entire country is forced to change phone numbers. It's still possible to lose a number for various reasons (most entirely benign). An oppressive government could definitely disrupt communication of suspects by forcing the phone company(-ies) to terminate th…
I got my mobile number in 1999 and already switched twice with the number. Sadly it is kinda expensive to take the number with you, 25 to 30 euros.
Earlier quoted context omitted.
I'd really appreciate more detail, here.
If everyone is using Conversations as their client, group chats work fine. Issues arrise when you introduce other clients into the mix ...
Or it's part of the protocol, but design decisions lead to client interoperability problems?
Maybe there's a third answer, but both of these are problems with XMPP.
Earlier quoted context omitted.
Also, most people are introduced to XMPP in ways that don't let group chats work very well, so they think that's an XMPP problem, not the service's.
How is that not an XMPP problem?