[HN Gopher] Is XMPP any good? Also, let's write a client in Tcl,...
___________________________________________________________________
Is XMPP any good? Also, let's write a client in Tcl, maybe
Author : wusspuss
Score : 91 points
Date : 2022-04-23 10:49 UTC (12 hours ago)
(HTM) web link (wusspuss.neocities.org)
(TXT) w3m dump (wusspuss.neocities.org)
| codr7 wrote:
| I tried to write a client back in the days.
|
| XML is always painful but XMPP brings it to another level by not
| playing nice with most parsers which expect complete documents, I
| ended up having to roll my own parser.
|
| But perhaps the situation in XML land has improved since, I
| sincerely hope so for the people writing today's clients.
|
| Professionally I've been involved in one project that used XMPP
| as a data protocol between back end services. It was eventually
| phased out in favor of REST because of buggy libraries which
| meant capturing messages in queues and replaying whenever the
| thing fell over.
| bigChris wrote:
| grishka wrote:
| The thing with the Nokia 5800 (I also have one) and other phones
| not designed in the US is that outside of the US, most people
| paid for SMS per message. So it made sense to present the
| messages in that UI, you're paying for the whole thing anyway,
| could as well use all 160 (or 70 around here) characters. No one
| in their right mind would split into several messages something
| that fit into one. For this style of instant messaging, we used
| ICQ. There were unofficial ICQ clients for just about everything.
|
| On XMPP itself -- I'm looking into it as the protocol for
| messaging for my federated social network. I first contemplated
| using Matrix, but then I looked at the spec, saw the mathematical
| notation for the room state synchronization algorithm, and noped
| outta there really fast.
| grishka wrote:
| And after reading the whole article, I'd like to add: it really
| helps to treat these protocols like APIs. As in, if you're
| building an XMPP server, you wouldn't want to expose the actual
| clients as resources, for example. You'd instead just send each
| message to each connected client and present them all as one
| single "client" to other users and for the purpose of s2s
| federation. That would eliminate an entire class of issues,
| like messages getting lost, AND improve the user experience at
| the cost of a slight, barely noticeable spec noncompliance.
|
| I do a variation of this for ActivityPub in my project already.
| Except I don't implement c2s ActivityPub at all.
| Arathorn wrote:
| mental note to link
| https://matrix.org/docs/guides/implementing-stateres from the
| matrix spec :p
| grishka wrote:
| Oh, thanks for this. I did look for a tutorial about
| implementing a minimally functional Matrix server like there
| are for ActivityPub[1][2], but didn't find any.
|
| [1] https://blog.joinmastodon.org/2018/06/how-to-implement-a-
| bas...
|
| [2] https://blog.joinmastodon.org/2018/07/how-to-make-
| friends-an...
| zaik wrote:
| If you're looking into XMPP for a social network, you might be
| interested in movim.eu (based on XEP-0277: Microblogging over
| XMPP) and the efforts to combine ActivityPub and XMPP:
|
| * https://nlnet.nl/project/Libervia/
|
| * https://inqlab.net/2022-01-17-activitystreams-over-xmpp.html
| buttocks wrote:
| I said this on a past XMPP thread. It is a dead protocol due to
| mobile. I loved XMPP but without a push system it is useless on
| modern mobile operating systems.
| Andrew_nenakhov wrote:
| XMPP works quite well with push on iPhones. I use it daily.
| usrn wrote:
| Dino and Gajim both work great on my Pinephone.
| grishka wrote:
| Client to server protocol is unimportant, you could as well
| roll your own that suits your use case. I do feel like XMPP is
| a good server-to-server protocol for federated instant
| messaging though. The only other one I know is Matrix, and it
| takes a much more convoluted approach by adding the requirement
| that each "room" is fully distributed across all participating
| servers. While it's something that's nice to have, it's not
| worth the hassle, imo.
| Nasreddin_Hodja wrote:
| > without a push system it is useless on modern mobile
| operating systems.
|
| If by "push" you mean sending notifications through 3rd party
| servers like google's Firebase, I'd like not to use it.
|
| I was using XMPP on mobile for years, receiving messages in
| background normal way almost with no battery drain.
|
| I also run k9mail 24/7 with my personal IMAP server, receiving
| messages in realtime (imap idle) with almost no battery waste.
|
| Battery is wasted more by bloated frameworks like Electron
| rather than by network activity itself.
| easrng wrote:
| > If by "push" you mean sending notifications through 3rd
| party servers like google's Firebase, I'd like not to use it.
|
| These days there's also UnifiedPush which is an open standard
| for push on Linux and Android. FluffyChat and SchildiChat
| (both Matrix clients) support it. I actually switched to
| SchildiChat from Element because Element's notification
| service was using too much RAM.
| zaik wrote:
| Network activity is quite significant for battery drain,
| thats why mobile XMPP clients do this:
| https://xmpp.org/extensions/xep-0352.html
| usrn wrote:
| No. Taking the wakelock is significant battery drain.
| Because of poor mobile OS architecture you have to take the
| wakelock to leave connections open. On normal Linux you can
| just have the OS suspend anyway and most of the time the
| connection will be there when it wakes up and if it doesn't
| the client automatically reestablishes. (this is exactly
| how the normal push connection on android is maintained
| anyway, there's almost no real overhead to having a couple
| more.)
|
| Mobile push is a combination of brain damage and bizarre
| propaganda targeting developers.
| Nasreddin_Hodja wrote:
| > Network activity is quite significant for battery drain
|
| It's not activity itself but what app does in background in
| reaction to incoming packets. Clients I used (Bombus and
| Xabber) didn't support that XEP with no problem. App may
| just ignore some stanzas when not needed.
| MattJ100 wrote:
| XMPP is widely used on mobile, it has supported push
| notifications for many years. Without it, you are right, using
| XMPP on mobile would be pretty painful, but that's not the
| case.
| bertman wrote:
| And yet, after all these years, mod_cloud_notify is still a
| community module and not even mentioned in
| prosody.cfg.lua.dist.
| MattJ100 wrote:
| Indeed, mod_cloud_notify is high on our list of modules to
| merge for the next Prosody release, if not the highest.
|
| A lot of effort went into Prosody 0.12, which we released
| recently. It's unfortunate that mod_cloud_notify didn't
| quite make the cut for that version, but it was better than
| delaying the long overdue release even further. The vast
| majority of work on Prosody is unpaid volunteer time, and
| as with most open-source work there are certain kinds of
| tasks which are hard to find funding for, leading to the
| old "it'll be done when it's done" because we (the
| developers) simultaneously need to pay our bills.
|
| Also, in recognition of many desirable things being in
| community modules, one thing we did prioritize in 0.12 was
| the plugin installer, which should make it easier for
| people to add additional modules to their Prosody
| installation.
| bertman wrote:
| Sorry, my comment probably came off way too snarky. Love
| Prosody and the work you do with Snikket.
| MattJ100 wrote:
| As someone who has been working with XMPP for a long time, I can
| safely say that most of the criticisms here simply have no
| material effects in practice. Yes, an ack packet can be 19
| characters long. Is that terrible?
|
| It would be just as easy to write a post like this about JSON,
| Matrix and so on. Both have many warts.
|
| But I really don't much care. No technology is perfect, and there
| will always be people who dislike choices that other people have
| made. What matters is what we do with the technology. XMPP has
| proven itself able to evolve over more than two decades, during
| which the internet and the way we use it has shifted
| dramatically, and yet it continues to be relevant as new people
| discover and adopt it.
|
| It's unfair to describe things like multi-device sync as
| "afterthoughts" when XMPP was one of the first real-time
| messaging protocols to have support for multiple concurrent
| connections of the same account built in, at a time before the
| iPhone was released, and most people had a single device with
| wired access to the internet only.
|
| Support for multi-device sync is part of the suite of protocol
| features required by modern XMPP implementations, these
| requirements are updated every year to account for the changing
| technology landscape: https://xmpp.org/about/compliance-suites/
|
| I personally like the simple delivery model of XMPP compared to
| the "distributed database" model that Matrix pursues. I think
| there are use-cases for both approaches. Both XMPP and Matrix
| have bridges between each other and third-party protocols
| (proprietary and open ones), which makes any attempt to create
| false competition between them an unhelpful effort. What's
| important is that both provide openly-documented protocols with
| open-source reusable implementations, and (in my opinion) most
| important of all: decentralized open communication networks.
|
| The problems facing the broader adoption of open networks for
| modern messaging are not protocol problems.
| dmitriid wrote:
| > Support for multi-device sync is part of the suite of
| protocol features required by modern XMPP implementations,
| these requirements are updated every year
|
| The problems is that many of these modern features were
| unbelievably late.
|
| I still remember "The State of Mobile XMPP in 2016",
| https://gultsch.de/xmpp_2016.html
|
| At the time, 9 years after iPhone had come on the scene, most
| modern features were still experimental draft proposals
| implemented by no one.
|
| 5 more years later there's maybe one client that implements the
| modern features (Conversations for Android IIRC), and that's
| about it.
|
| And it's an unknown how many servers implement those features.
| seba_dos1 wrote:
| > 5 more years later there's maybe one client that implements
| the modern features (Conversations for Android IIRC), and
| that's about it.
|
| ...and yet I'm using three different modern clients that work
| well with each other.
|
| > And it's an unknown how many servers implement those
| features.
|
| Enough to make me not have to care about it.
| MattJ100 wrote:
| > And it's an unknown how many servers implement those
| features
|
| It's not: https://compliance.conversations.im/tests/
|
| Obviously a new user is not expected to fathom what all this
| means before getting started, which is why there are curated
| lists of public XMPP services, e.g.
| https://providers.xmpp.net/ and https://joinjabber.org/ and
| for private servers there are projects like Snikket where the
| server software is developed in parallel with apps to ensure
| a consistent feature set.
| ajconway wrote:
| Yet Matrix is gaining traction while XMPP is not. Maybe the key
| was to have funding, build and run a reference server and
| quickly iterate with a reference client for all major
| platforms.
| olah_1 wrote:
| > Yet Matrix is gaining traction while XMPP is not
|
| Considering the way in which Matrix spreads unencrypted
| metadata (even rooms and participants in the rooms, let alone
| chat events) as far as possible across the network, this
| traction is quite insidious.
| wusspuss wrote:
| How much worse than XMPP is Matrix in this regard? On XMPP
| your and your interlocutor's server can see who you talk to
| zaik wrote:
| Not a lot better, but in public MUCs your JID is hidden
| to everyone except the server the MUC is hosted on. Also
| MUCs can be configured to only send a limited amount of
| history to new participants.
|
| For this reason I'm somewhat uncomfortable joining Matrix
| rooms over bridges, since it leaks my XMPP address and
| participation to everyone forever.
| Zash wrote:
| Maybe the key is network effect and enough marketing to
| bootstrap it?
| ajconway wrote:
| It doesn't look like Matrix has reached the point where
| there is any significant network effect. What I'm saying is
| that they are building a product, and the protocol is just
| one component of that product.
| zaik wrote:
| The key to interoperability is agreeing on standards.
| XMPP being about creating a proper Internet Standard and
| not a product is what made me choose XMPP over Matrix
| (also simplicity).
| wusspuss wrote:
| Not losing messages is pretty key too. But yeah, given
| enough marketing you can pull anything off. WhatsApp
| basically doesn't support multi device to this day and is
| more popular than either (free) XMPP or Matrix could ever
| hope to be. There's a web version but it only works if your
| phone is connected. So I guess the phone acts as a server
| then? Does that mean they found it easier to set it up like
| that than to make xmpp (which WhatsApp is said to be based
| on) reliable with multiple devices?
| Andrew_nenakhov wrote:
| XMPP working on multiple devices is a problem long
| solved. Not losing messaging is a solved problem too. I
| can schedule you a demo if you wish.
| memen wrote:
| That is not true anymore. The latest version of WhatsApp
| Web can be used without your phone connected. Not sure if
| it is rolled out globally for everyone yet, as it was
| fairly recent for me (couple days now).
| mnd999 wrote:
| WhatsApp has traction, discord is gaining it. Matrix isn't
| really anywhere.
| IgorPartola wrote:
| After trying Matrix as a Discord replacement with a couple
| of different clients it was pretty terrible. My Discord
| usage is fairly simple but I run a community for non-
| technical people. Matrix UX was pretty shit between
| confusing clients and just the overall clumsiness. I would
| have loved to introduce a whole community to it but instead
| I went back to Discord instead.
| mypalmike wrote:
| I hardly spend any time using it, but when I do, I find
| discord's UI to be complex and confusing.
| IgorPartola wrote:
| I run a server for a non-tech community with roughly 300
| members ranging in age from 20 to 65. Some of them are
| extremely non-technical, to the point that they say "hey
| Siri turn on flashlight" instead of finding the button on
| their phone. Every single one was able to figure out
| Discord in a matter of minutes and use it daily with zero
| complaints. I would say that's a customer success story
| right there.
| MattJ100 wrote:
| > Yet Matrix is gaining traction while XMPP is not.
|
| I'm curious what you base this on. Without a doubt Matrix is
| gaining traction. It's a relatively newer project, has some
| new ideas, and there is a lot of buzz around it. But it has
| far to go before reaching XMPP's levels of achievement -
| millions of XMPP-connected users via Google Talk, and popular
| products such as WhatsApp and Zoom built on top of it. That
| many of these aren't, or are no longer, interested in
| interoperability or federation is not a protocol problem, and
| I don't see Matrix solving that.
|
| XMPP continues to be widely used by individuals,
| organizations and governments who want more control over
| their communication. Across the XMPP projects and services
| I'm involved in, I continue to see plenty of new users and
| developers joining the community.
|
| The reference client/server is definitely a pattern I agree
| with you on, however. It has served Matrix well, and others
| too. I've been a proponent of this approach for some time,
| and detailed my thoughts in the "Products vs Protocols"
| talk/post at https://snikket.org/blog/products-vs-protocols/
| wusspuss wrote:
| >But it has far to go before reaching XMPP's levels of
| achievement - millions of XMPP-connected users via Google
| Talk, and popular products such as WhatsApp and Zoom built
| on top of it. That many of these aren't, or are no longer,
| interested in interoperability or federation is not a
| protocol problem, and I don't see Matrix solving that.
|
| But these aren't the protocol's achievements either. These
| people have so much money they could make IRC popular.
| wusspuss wrote:
| >I personally like the simple delivery model of XMPP
|
| The moment you ask for reliability it stops being simple.
| Stream Management + Stanza Ids isn't simple, and it shows -
| XMPP is the only thing I use today where it occasionally
| happens that a message isn't delivered and I'm not even
| notified about it.
|
| On a side note I don't believe that this can't be fixed. Maybe
| if we had end clients checking directly with each other what's
| been delivered and what hasn't, like actual humans end up doing
| anyway, I believe it'd be more reliable. Besides instead of
| relying on the c2s-s2s-s2c cooperation chain to work, it'd rely
| on just c2c cooperation, giving much fewer variations to test.
| Just to clarify I'm not talking about a p2p connection but
| rather e.g. checking the number of stanzas not with the server,
| but with the interlocutor's client, through the normal XMPP
| means, like <iq/>s maybe
| MattJ100 wrote:
| I'm not really sure how to silently lose messages in XMPP
| these days, if you use stream management (which everyone
| does[*]).
|
| The last gap I'm aware of was that if you sent a message to
| someone on a remote server, and the remote server couldn't be
| connected to, your server would generate a delivery error
| (i.e. not silent). _But* if you went offline before this
| delivery error reached you, you would never see it. These
| days such errors are stored in the user 's message archive,
| and available to all your clients for synchronization
| purposes (so all of them can see that the message failed to
| deliver).
|
| So with that said, I'm very interested in hearing any details
| you can provide about how to silently lose messages in modern
| XMPP. Clients involved, steps to reproduce, etc. Then we can
| produce actionable bug reports.
|
| [*]: I believe Pidgin is still a notable exception here.
| Notable mainly because a lot of people still use it, even
| though its protocol plugin development has stalled somewhat
| for many years (the project is still being developed, but
| their focus has been on core/foundation improvements rather
| than keeping up with changes to modern internet messaging)._
| wusspuss wrote:
| >So with that said, I'm very interested in hearing any
| details you can provide about how to silently lose messages
| in modern XMPP. Clients involved, steps to reproduce, etc.
| Then we can produce actionable bug reports.
|
| Conversations, draugr.de, can't really say much on steps to
| reproduce - it worked reliably and then it didn't just
| yesterday, ironically just as I tried to send the article
| to a friend to check out.
|
| If I understand the two generals' problem correctly, there
| _always_ is a way to silently lose messages, with any
| protocol, it 's just that some approaches to not doing that
| are more reliable than others
| MaulingMonkey wrote:
| > there always is a way to silently lose messages
|
| That's a bit overgeneralized.
|
| A simple protocol for message delivery that will not
| silently fail: resend it (presumably with a unique
| identifier of some sort to avoid duplication),
| pessimisticly and loudly pointing out "failure" (really:
| ambiguity of delivery), until you get a reciept of
| delivery.
|
| What the two generals problem points out for this
| protocol is:
|
| 1. the sender of the reciept won't be certain that said
| reciept was recieved
|
| 2. the message may be successfully sent before the sender
| realizes it
|
| 3. if communication is permanently severed, the sender
| may forever be uncertain if the message ever got through
| or not (but this can be messaged loudly and
| pessimistically to the end user)
|
| This creates design problems for coordination of
| consensus for things like database transactions, but a
| chat client failing to alert to potentially undelivered
| messages is just bad, not merely running afoul of some
| fundamental law of information science.
|
| Of course, it's always possible to successfully send and
| recieve reciept of a message, only for the recipient's
| server to suddenly catch on fire and explode before
| backups are made, thus permanently losing any record of
| said message, but that's more of a "two generals and an
| assassin" problem, outside the scope of the original
| thought experiment. It is also, hopefully, a rarer
| scenario than packet loss.
| InfiniteRand wrote:
| I think the decline of xmpp can be traced to the rise of text
| messaging and phone messaging in non-open protocols. One factor
| that made non-open protocols more palatable on the phone than
| on the desktop is the easier and relatively more secure nature
| of phone apps (I don't think phone apps are that secure, but I
| think they are more secure than installing random exe's on your
| computer). If you're willing to install all of the apps, yeah
| having everything in one place would be convenient, but there's
| only two or three apps you care about so it's not a huge thing.
| Moreover most of the phone apps liked to keep things closed.
| That's just my thinking.
| hot_gril wrote:
| I've worked with XMPP for years, and I say it's bad and
| outdated. The criticisms linked are all valid, and there are
| good reasons it's being abandoned. Was a great protocol back
| when it was the open alternative to AIM.
|
| About the XML bloat you've mentioned: The problem isn't just
| the wire size, it's working with it as a developer. XML is
| needlessly complicated to deal with in code and super painful
| to read when debugging. Tooling for it seems lacking too; I
| even found that iOS's built in XML parser was very slow at
| parsing large elements, with time/mem used seemingly growing
| O(N^2). Found that out when the XMPP-using startup I was
| working for decided to send all their XMPP IQ messages as just
| wrapped JSON payloads.
|
| About extensions: As cool as those XEPs are, it makes for a
| fragmented federated ecosystem when so many basic features are
| extensions. It's not awful when maybe you can't send large
| files on one server, but when something like auth is broken...
| eternityforest wrote:
| I call it a "pseudostandard". When you need extensions to use
| it at all, and half the clients are missing just enough of
| them to be useless for half the users.
|
| Plus it's confusing. You have to look through feature
| matrices instead of just saying "Oh this is version 4, it has
| everything I need".
| Andrew_nenakhov wrote:
| > XML is needlessly complicated
|
| For messaging purposes, it is absolutely identical to JSON in
| this regard. Once you have many existing implementations out
| in the wild that need to interact with each other, you'll
| need namespaces or their NIH analogue. And JSONs with
| namespaces will be just as bloated as XML.
|
| Understand this: xml is meant to be read by computers, not
| humans.
|
| > The criticisms linked are all valid, and there are good
| reasons it's being abandoned
|
| It's 2022 and there is still nothing better for federated
| messaging.
| andrewshadura wrote:
| > It's 2022 and there is still nothing better for federated
| messaging.
|
| That is untrue. Matrix is undoubtedly much better.
| jhugo wrote:
| No matter how many times you say that, it still won't be
| true. A mere few minutes spent looking at the Matrix
| protocol and a few minutes spent looking at XMPP (if you
| can get past the fact that it's XML) will make that
| clear. Matrix is basically a case study in how not to
| design a federated chat protocol. It's bloated, it
| ignores all prior art and reinvents the wheel everywhere
| it can, and its excessive complexity means there is
| unlikely to ever be a wide ecosystem of good-quality
| implementations (especially of servers). Just because
| they made a foundation and threw around the word
| "standard" a lot doesn't mean it deserves to be the
| standard for chat protocols.
| eternityforest wrote:
| Matrix might have bad core tech, but they are one of the
| only groups working on the biggest issue with federation.
|
| Tying identity to a server is insane in a decentralized
| environment. Decentralization is all about keeping Google
| sized companies from controlling things. But small
| companies come and go all the time, and nobody trusts
| them to be around in 10 years.
|
| They aren't solving the SSL problem though. Mumble has a
| good solution their with their trust on first use
| connections. Self hosted really should ideally not need a
| domain name if you want individuals to host it. It should
| be something you can literally buy a $20 preconfigured
| hosting node, plug it in, and go.
|
| Tox seems to be most promising of current ones, it just
| needs to fix it's mobile data use issues.
| Andrew_nenakhov wrote:
| > but they are one of the only groups working on the
| biggest issue with federation.
|
| This issue you are talking about is reliably solved ny
| owning your own domain. You can self-host it or use the
| commercial provider for it, either way you can change
| provider and retain your address.
|
| And regarding these matrix guys, they are so overtaken by
| a NIH syndrome [1] that they couldn't even follow a
| common URI syntax. Are you really sure they are best fit
| to develop standard protocols of any kind?
|
| [1]: https://en.m.wikipedia.org/wiki/Not_invented_here
| andrewshadura wrote:
| > A mere few minutes spent looking at the Matrix protocol
| and a few minutes spent looking at XMPP (if you can get
| past the fact that it's XML) will make that clear.
|
| You're right, Matrix immediately stands out as what XMPP
| should have been from the beginning.
| wusspuss wrote:
| >No matter how many times you say that, it still won't be
| true. A mere few minutes spent looking at the Matrix
| protocol and a few minutes spent looking at XMPP (if you
| can get past the fact that it's XML) will make that
| clear.
|
| Maybe judge not by reading protocol description but by
| trying and using said protocol, like, chatting with
| people a lot? With the latter approach you'll notice a
| very handy feature of Matrix - not losing messages.
| Andrew_nenakhov wrote:
| Lol no. It is a monolithic monster that will never see
| any other independent server vendor. Matrix is a product
| with a public API, not a protocol.
| andrewshadura wrote:
| This is, again, untrue.
| Andrew_nenakhov wrote:
| As jhugo said in a sister subthread, it doesn't become
| true if you repeat it again and again.
| wusspuss wrote:
| >For messaging purposes, it is absolutely identical to JSON
| in this regard.
|
| There's no "JSON mindset" to produce anything comparable to
| this crime against bandwidth and code brevity:
| <stream:stream from="draugr.de" id="{ID}" version="1.0"
| xmlns:stream="http://etherx.jabber.org/streams"
| xmlns="jabber:client">
|
| Being sent on every connection for no reason, thrice (!)
|
| >Once you have many existing implementations out in the
| wild that need to interact with each other, you'll need
| namespaces or their NIH analogue. And JSONs with namespaces
| will be just as bloated as XML.
|
| Even XMPP, with XML, could do just fine without namespaces.
| The only place where namespaces are the differentiating
| factor in practice is <query/>'s and <x/>'s. Couldn't they
| just be be called <mam_query/> or whatnot? Oh, and
| namespaces specify the version. Like for ack's they specify
| the version 3 every time. But it's something that has to be
| (and is) clarified when enabling said acks anyway.
| easrng wrote:
| JSON with namespaces exists, it's called JSON-LD, and it's
| used by ActivityPub among others.
| wusspuss wrote:
| >It would be just as easy to write a post like this about JSON,
|
| JSON has no namespaces, even without taking that into account
| it's already less verbose, it maps nicely into lists and dicts,
| I don't know a single JSON parser that can leak the user's IP
| even as an option, let alone by default (not saying there
| aren't any at all, just no popular ones), doing a binary
| version of XMPP based on JSON would take as much as switching
| over to bencode instead of whatever the unsupported hell EXI
| is. So no, you can't really write a post like this about JSON.
| Even if you do, it's not gonna be XML that will be proposed as
| a better solution.
|
| One thing where XML beats JSON is markup. But with XMPP's
| unholy approach to markup, it's actually JSON that beats XML.
| progval wrote:
| > JSON has no namespaces
|
| Causing all extensible JSON-based protocols to eventually
| reinvent them:
|
| * https://www.w3.org/TR/json-ld11/#compact-iris
|
| * "If new events are added, the event type key SHOULD follow
| the Java package naming convention, e.g.
| com.example.myapp.event."
| https://spec.matrix.org/v1.2/client-server-api/#types-of-
| roo...
|
| * https://datatracker.ietf.org/doc/html/draft-ietf-
| oauth-v2-22... (no aliases, so it's even more verbose)
|
| * https://github.com/OAI/OpenAPI-
| Specification/issues/1362#iss...
| InfiniteRand wrote:
| Namespaces address a real concern that inevitably comes up
| in protocols dealing with complex data and combining syntax
| from different standards or sources. That being said it is
| very easy to make half-assed solutions to the problem of
| namespaces, and the full-assed solution for namespaces is
| always a little complex and brittle, so it isn't surprising
| to me that most people end up going the half-assed route.
| jancsika wrote:
| Wait a sec.
|
| By far the most widely used half-assed solution to
| namespaces is in the HTML5 parser to special case svgs
| (and maybe other curiosities? Dunno). And if I understand
| correctly, that happens to be a full-assed specified
| algorithm that all current browsers use.
|
| That is all in order to _avoid_ the problems that would
| have come with requiring the full-assed XML namespaces in
| that case.
|
| If I were a political operative, I would attempt to bog
| down the XML apologists on _this_ point whenever they
| attempt to argue that JSON gets as complicated as XML
| when you try to include namespaces.
| wusspuss wrote:
| It's not the lack of namespaces that causes people to
| reinvent them. Using or not using namespaces is a choice
| you take. With XMPP it's 100% dictated by the XML mindset.
| There is NO reason for <starttls
| xmlns="urn:ietf:params:xml:ns:xmpp-
| tls"><required/></starttls>
|
| to specify urn:ietf:params:xml:ns:xmpp-tls other than
| formalism/a yearn for bloat. There would never be a name
| collision without this ns and it convenes no useful info.
|
| There's no reason for acks to specify urn:xmpp:sm:3 each
| time. Yes, here it at least specifies the version, but
| that's already negotiated when enabling acks anyway.
|
| There's no reason why <query xmlns='urn:xmpp:mam:2' .../>
| can't be <mam_query .../>.
|
| Namespaces are a choice, sometimes (e.g. in programming
| languages) reasonable, sometimes (in a serialization format
| for passing small texts around) not so much.
|
| It is dictated by a mindset, the XML mindset in case of
| XMPP, and in the case you bring up apparently by the Java
| mindset, not to say there's much of a difference between
| the two
| Andrew_nenakhov wrote:
| Switching to JSON over XML would solve approximately zero
| problems that decentralised communication protocol faces. In
| fact, it would only make things more complicated and less
| flexible.
| TedDoesntTalk wrote:
| The protocol can be perfect. But unless there are great clients
| for it on multiple different platforms, and those clients
| implement all the awesome optional protocol features, it just
| doesn't matter.
|
| * Screen sharing * File sharing * Sync across devices * Group
| chat without fuckery * Ability to delete and edit messages *
| Notifications of new messages
|
| I know XMPP supports all of this and more. But find a cross
| platform client/server that implements all of it?
|
| Then look at the clients for matrix, telegram, signal, teams,
| whatsapp, and others.
| olah_1 wrote:
| > I know XMPP supports all of this and more. But find a cross
| platform client/server that implements all of it?
|
| That is what Snikket is trying to be.
| https://github.com/snikket-im
| tcfhgj wrote:
| I can't find anything regarding Support for multi-device sync
| there. I don't know any client which even claims to support
| something like this.
|
| I only know about MAM which doesn't work with E2EE... and
| depends on the individual chatroom's server.
|
| > Both XMPP and Matrix have bridges between each other and
| third-party protocols (proprietary and open ones), which makes
| any attempt to create false competition between them an
| unhelpful effort.
|
| Bridges don't really work with E2EE anymore...
| Andrew_nenakhov wrote:
| > MAM which doesn't work with E2EE...
|
| Soo first you want E2EE so nobody can tap into your
| conversations, and then you want to receive text of you
| messages from the server archive? :hmm emoji:
| Semaphor wrote:
| Shouldn't that be no issue as long as either both clients
| use the same key, or the messages have been encrypted for
| both keys?
| Andrew_nenakhov wrote:
| It is not an issue at all. I was just highlighting a
| nonsense criticism about message archive and e2ee.
| tcfhgj wrote:
| no, I just want multi device sync like what WhatsApp and
| Matrix offers
| Andrew_nenakhov wrote:
| That is easily possible with XMPP and does not really
| have anything to do with 'MAM supporting E2EE'. For
| Message Archive all messages are equal, encrypted or not.
| tcfhgj wrote:
| then tell me with what constellation of apps this
| actually works
| zaik wrote:
| What did you try? I'm using Conversations on mobile and
| Gajim on various workstations and they sync nicely (I
| think?).
| Andrew_nenakhov wrote:
| Web/iOS versions of Xabber do it quite well, complete
| with videocalls and screensharing, etc.
|
| Android version is in rewrite (decided to dump existing
| app because of tech debt issues), but I have zero reasons
| to doubt that it will work (hopefully by august).
|
| iOS version is not yet released on Appstore because we
| need to work out some more issues (not too many), but I
| can give you access to it, if you're interested.
| tcfhgj wrote:
| i wanted to try sync with two sessions; I havent been
| able to create a group. After accidentally aborting group
| creation, i couldnt try again for a while. When i git the
| dialogue open again, and filled all the stuff in, the
| create button simply doesnt react.
| Andrew_nenakhov wrote:
| I have no idea of what you are talking about. Likely your
| are using a rather old version of web client. Email me
| andrew.nenakhov@redsolution.com, I'll schedule you a demo
| of our latest stuff.
|
| (We're currently not considering everything ready for
| public release, thus apps available to public lag from
| what we ship to our customers and use ourselves)
| tcfhgj wrote:
| I used the live version: https://www.xabber.com/web/
| Andrew_nenakhov wrote:
| It is a three years old version that uses stock ejabberd
| 2019 version. It is far behind our current state of the
| art. We plan to update it with the next server release,
| but we have only four hands each so it'll take us a
| while.
| xeeeeeeeeeeenu wrote:
| While the technical problems were certainly one of the main
| factors contributing to the decline of XMPP, I think that
| branding was also a big issue. They had a perfectly good name
| that was gaining traction ("Jabber") and then they suddenly
| changed it to XMPP, confusing everyone in the process.
| MattJ100 wrote:
| Yeah. This wasn't an intentional thing by the community. The
| "sudden change" was due to the acquisition of Jabber Inc. by
| Cisco, which included the "Jabber" trademark. There is a
| trademark agreement with XMPP Standards Foundation to allow
| open-source projects to apply to use "Jabber" as part of
| their name. However, unsurprisingly, the community around the
| protocol rallied around "XMPP" as the safer term, while Cisco
| moved forward with their "Jabber" product.
|
| I think it has taken too long for the community to realise
| what an asset a good brand can be, and that it's hard to
| rally normal users around a protocol and an ecosystem rather
| than a product. I think that's growing to change though, with
| a number of user-focused projects around the ecosystem
| (including Snikket, the one I'm working on).
| upofadown wrote:
| How old is this article? It talks about client to server
| encryption like it is some sort of optional thing.
|
| >Today you expect a messenger to be a database.
|
| I do? Not all of us want the levels of resource utilization this
| approach requires. Why would I want to be able to edit/delete old
| messages? I can just send new ones.
| Andrew_nenakhov wrote:
| > Everything that we expect today - chat history, reliable
| message delivery, multi-device synchronization - is an
| afterthought in XMPP.
|
| The author grossly misunderstands XMPP. The first letter X stands
| for "eXtensible", and extensible it is.
|
| Chat history, milti-device sync, reliable message delivery is not
| an afterthought, it is extension (and btw they all are solved
| problems as of now) The protocol is by design modular, and it is
| a strength, not weakness.
|
| You can't realistically expect all the world to share the same
| version of your monolithic messaging protocol. Different
| instances will support different features, some implementations
| will lag on with newer features, etc. The only possible answer to
| this is modularity and legacy fallbacks for some features that
| are not supported by remote party.
|
| Sure, the protocol could develop more rapidly. I actually believe
| that XMPP survives despite efforts of the XSF coincils, not
| thanks to them. However, the core of the protocol is strong and
| allows to build communication products with UX not worse than
| Telegram or Discord. And if you lack some crucial feature like a
| properly working group chat, you can make your own XMPP extension
| - _because eXtensible it is_.
| rcxdude wrote:
| In most people's mind extension = optional = afterthought.
| Especially this is the case if you cannot guarantee that
| something which supports the protocol actually supports the
| feature then it's difficult to use that feature. The main point
| is that the mentioned features are no longer optional for a
| 'chat protocol', any protocol which does not have them as core
| or required features is not going to be considered meeting the
| requirement of 'chat protocol'.
| Andrew_nenakhov wrote:
| Most people's mind do not care about protocols, they think of
| products. And speaking of products, every major xmpp server
| implementation I know (and I know at least five) supports all
| these features.
|
| Also. You don't really need any of them to send messages
| between servers. All this stuff matters only for
| communication between your clients and your own server.
| [deleted]
| arendtio wrote:
| I have the impression that the discussion around XMPP isn't going
| anywhere. On the one side are the people who say it is outdated
| and can't handle mobile/multi-device/energy-efficient
| communication and on the other side are the people who argue,
| that XMPP got extensions to handle all those cases. I am part of
| the later group.
|
| However, instead of arguing I think it might be better to give a
| short summary about the state of XMPP from a users perpective. I
| use XMPP every day for several years now. In my opinion the best
| clients are the following:
|
| - Linux -> Gajim (also available for Windows)
|
| - iOS -> Siskin
|
| - Android -> Quicksy/Conversations
|
| Especially Siskin has made great progress over the past year.
| While these clients can do most of the things you would expect
| from a modern IM client, there are still a few weak spots:
|
| - The combination of OMEMO (End-to-end encryption) while using
| multiple (clients over longer periods of time) can lead to
| situations where some clients can't decrypt messages. This is
| rarely dramatic (because one of your devices can decrypt the
| message), but can be annoying.
|
| - It seems video calls across different clients are work-in-
| progress. Conversations to Conversations works fine, but with
| Siskin I had some trouble.
|
| So the bottom line is: Most things work fine, but some things
| don't.
| icedchai wrote:
| About 10 years ago, I worked on an XMPP client and experienced
| many of these issues. Fun times.
| kseistrup wrote:
| There alread _was_ an xmpp client in tcl/tk: Coccinella
|
| [?] https://en.wikipedia.org/wiki/Coccinella_%28software%29
| Nasreddin_Hodja wrote:
| There was Tkabber also.
| kseistrup wrote:
| Ah, yes!
| libx wrote:
___________________________________________________________________
(page generated 2022-04-23 23:01 UTC)