Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Why is JSON better than XML? It's more modern, sure, but from technical perspective it is not objectively better right? Not something worth switching protocols for.
You mention XMPP has transports as opposed to Matrix bridges. I thought they give you roughly the same outcome. What's the difference?
The only things JSON has over xml is that it’s easier to write a parser for it and the format is less verbose and less complicated. There are extensions to JSON that can add features that xml has and the JSON spec doesn’t have. Overall the xml spec is bigger and has more features but that also makes it overkill for many of the cases that it would be used in.
XML is unnecessarily complicated. By trying to cram everything into the spec, it's cumbersome and hard to parse.
The goal is the same, but the way they archive that is different. For transport to work, you need an account on each platform you are using the transport on. It relays the messages through that account by mimicking the client. While bridges work by relaying the messages between rooms and not specific users.
My understanding is limited, so if you are interested, please do your own research.
Most Matrix bridges to commercial chat systems also require accounts on those networks. That's the only way to make them work on most of these systems.
I guess you are specifically referring to the Matrix to Discord bridge that does work like you describe, but a similar bridge has existed for XMPP to Discord in the past but is currently broken and unmaintained. The currently working XMPP to Discord transport does require you to puppeteer a personal Discord account, but that is rather because of a different focus of the used transport framework than any technical limitation of XMPP in that regard.
All platforms that don't have public API access will require a way to relay that information, but I was talking about the difference in how the messages are relayed. Matrix bridges work fundamentally on each platform/protocol having its own room and relaying the messages through the bridged room instead of the user as XMPP does. That's why you can relay the same messages to multiple rooms on Matrix, but can't do the same on XMPP.
No, that is only an implementation detail, you can easily do a very similar thing with XMPP group-chats.
In fact the way Matrix does it is a major limitation and the source of an endless amount of issues with their IRC bridge.
Parsers have already existed for so long in every major language. Why need to worry about parsing?
And why need to worry about transports working differently if they achieve the same thing? They seem similarly convenient if I understood what you said correctly
Additionally, libraries for XMPP exist in most languages, there is a varying degree of completeness, but they all do a good job of hiding XML from the programmer