I think that happens when as a German you're used to using the Plusquamperfekt which is a somewhat unique tense that's allowed to be used in all past tenses.
It allows you to not having to define the point in time and neither the frame of the timespan's points in time.
Some languages allow to use that type of tense and it's somewhat a language gap I suppose. I have no idea what other languages or proto languages allow that tense though, but I've seen some Slavic and maybe Finnish(?) natives use that tense in English, too.
Maybe someone more elaborate in these matters has better examples?
You are replying to someone whose account name is tabs_or_spaces, which in itself is so ironic that I have no word for it.
What people don't seem to realize is that like you pointed out there's a demand for the previous "developer relations" type of job though, and that job kind of evolved through LLM agents into something like an influencer(?) type position.
If I would take a look at influencers and what they're able to build, it's not that hardcore optimized and secured and tested program codebase, they don't have the time to acquire and hone those skills. They are the types who build little programs and little solutions for everyday use cases that other people "get inspired with".
You could argue that this is something like a teacher role, and something like the remaining social component of the human to human interface that isn't automated yet. Well, at least not until the first generation of humans grew up with robotic nannies. Then it's a different, lower threshold of acceptance.
Discord probably still claims they weren't hacked. How they handle incidents like this matters to a lot of folks, and that's what this is about.
3 months after a major breach, how could anybody possibly believe that they fixed all their wrong organizational policies and security measurements within that time, while still not even acknowledging the incident?
I was reading through the complete issue thread and I have to say I probably would side with the wolfSSL maintainers in part but they could have handled it in a nicer way.
"Anthu" only responded with this after "feld" asked why the issue was closed by them, and only then the response you mentioned was written.
"Anthu" could have simply asked before closing the issue and the reporter would have been fine. Like, say "So, this issue meanwhile evolved into RFC compliance and got a bit off track in my opinion. Can you please open up a separate issue for this so we can get this fixed in a more focused manner? That would be very helpful for our workflow. If not, I would open up an issue and reference this one if that's okay with you."
My point is that feld felt a little ignored in their problem, and the support role could have handled it a little nicer. I get that maintainer time is limited, but I would probably recommend an issue template for these matters where there's checkboxes in them like "keep it short, keep it reproducible" and maybe a separate issue template and tag for RFC matters.
On the other hand, "feld"'s blog post reaction was also quite trigger happy and in part in bad faith. They could've communicated the same things in a "non rage mode" after things have calmed down a bit.
Funny how back then people claimed peak stability was Windows 2000. 10 years from now people will look at Windows 10 and claim that was peak stability.
This article spoke to me, a lot. I had a similar experience, though I started with a "leftover" C64 that my uncle didn't need anymore when I was a child.
All the magic was in those magazines, where people shared code, optimizations, explanations, and new programs and games. In each of those magazines people were writing letters to the publisher team with their modifications. It was pretty awesome how the community spirit worked and shared the creative enthusiasm through "paper channels" before the online age.
Then came github. Github was amazing, the /explore page was my new tab page for at least the first 5 years. I loved the exploration part of what other humans built, what kind of ideas they had, and where they wanted to go with their projects. I just loved reading code and learning from it.
Now, post github and post LLM, I don't know what this means anymore. Doxxing communities rule the internet, people are abusing hate and misinformation to enforce their political views. The remaining ones try to shield themselves from information overload syndrome.
But what does it mean to contribute now? Are humans now something like Christoph Waltz in Zero Theorem? Algorithm monkeys training the AI at an input console? Is that what humanity envisions as its future these days?
I still build software, but my approach has changed. I am scared for future generations that will have forgotten how to read books, and where the knowledge and hacking spirit has been lost completely. So I am spending the time I have left optimizing for that future, because the trend of short lived media excessively emotionalizing every topic is clearly going there.
Maybe, some day in the future, a kid will read my wiki and be amazed on what you can do with a computer. That's enough motivation for me to keep going.
My goals are pretty clear for now:
- make knowledge decentralizable
- write down all the basics I need to know to exercise my craft
- write tools to combat surveillance, censorship, and cyber warfare
The problem with XMPP is that it's a suite of RFCs.
It's like describing DNS, which is a conglomerate of RFCs so complex that it's unlikely to be implemented correctly and completely.
XMPP is a design fail in that regard, because if you have to tell your chat contacts to download a different client that fulfills OMEMO or XEP-whatever specs, then yeah, ain't gonna happen for most people.
(I am still a proponent of XMPP, but the working groups need to get their shit together to unify protocol support across clients)
This has been brought up on HN before, and people smarter than me identified that this view is about 10 years out of date.
Yes it's a bunch of XEPs, but there are standardized "sets" apparently that include all of the things any other similar tools do. It sounds like only very niche old/minimal XMPP clients don't support encryption by default for example, and virtually all servers have supported it for many years.
Is there a recommended or "blessed" server and client combo for someone who just wants to migrate their friends off discord?
The main site https://xmpp.org/software/ lists lots of different options but I have no idea what core/advanced means and comparing all of these would take ages.
The ironic part is that those software description files are meaningless. AstraChat claims Advanced in all categories, but it's a proprietary commercial software, so nobody ran any kind of test suite to verify this.
That software list, how it's done and how it's ranked is literally confirming my initial point of critique :D
Last time I tried out several chat clients, most of them were alpha software, had lots of bugs appearing in normal conversation flows, well, or were so broken that they broke compatibility in subminor version updates to their very same client apps.
I just wish there was some kind of ACID test suite for XMPP or something else to reproducibly validate spec compliance. Maybe a test server or similar as a reference implementation. This way client or server maintainers would have to run their programs against the official test server to increase their compliance stats.
> I just wish there was some kind of ACID test suite for XMPP or something else to reproducibly validate spec compliance. Maybe a test server or similar as a reference implementation. This way client or server maintainers would have to run their programs against the official test server to increase their compliance stats.
This is exactly what the Compliance Suits are for, and the XMPP Software Fundation is taking care of telling all the clients what they misses directly on the official website, for example: https://xmpp.org/software/movim/
There is the XMPP Compliance Tester[0] by the author of Conversations. It does a good job at testing servers. On the client side I'm not aware of any kind of benchmark.
Because the declaration file of the clients says that it is actually compatible with everything in this section.
You can't run scripts on all the XEPs declared, some of them are purely redaction or bound to specific UI/UX behaviors. This is based on trust that the developers actually implemented things as stated.
Not being able to automate something is not the same as not being able to verify at all. It sounds like the parent commenter is arguing that at least some of the clients listed are not worthy of this trust because (either intentionally or due to developer error) they don't actually hold up to scrutiny. Obviously they're just one person and their opinion might not be representative but it's hard to argue that if some random user is expected to have enough time to try out various clients and figure out which ones work or don't that the official people in charge of making the recommendations of clients should probably be able to find the time to as well even if it's just a volunteer that they, well, you know...trust.
Hasn't social media like HN, Reddit, fediverse, etc. become the real clearinghouse of information about those sorts of questions? I can see how it would be nice for xmpp.org to be an authoritative source of truth, but user response/consensus seems more relevant these days, at least to me.
The targeted audience of this website is, for now, developers. Communicating is hard.
https://joinjabber.org/ is/was an attempt at something more user-focused. It is not linked to the XMPP Software Foundation. BTW, joining the XSF and participating in discussion around protocol evolution, communication strategy and these sort of things is free, and only requires asking for write permission on the XSF wiki to add an application page. Everything happens in the open (mailing lists, chat rooms). We value democratic processes.
>Is there a recommended or "blessed" server and client
Not sure about servers, but for clients there's Gajim, Dino, and Conversations. Not much else is super relevant these days. Profanity exists but is significantly worse than irssi or weechat despite looking superficially similar. Kaidan is a KDE/Qt alternative to Gajim but I'm not sure if it's usable yet. It may be worth switching when it's fleshed out to escape the bugs and slowness of the GTK-based clients.
If you stick with mobile use, there is Snikket[0], which provides a branded server+mobile app ecosystem that should "just work". YMMV; I haven't tried it myself.
The developer is very active in updating and maintaining the software (both client and server), and it already supports most of the XEPs.
It's open source and fully supports self-hosted as first class, but if you want to support the developer he offers a cloud hosting paid offering as well. There's a crossover offer with JMP.chat too. If you pay $5 upfront for your first month of JMP.chat, you can get a free cloud hosted Snikket server for it to be setup on. As long as you maintain at least one number with JMP.chat, you keep the server maintained. If you don't, you get a chance to migrate your data. The Snikket cloud server gives you an XMPP server admin account, and you can setup as many accounts as you want. The caveat is that Snikket implementation is optimized for <1000s of user accounts per server.
Monocles chat is best one for Android, it is the most complete chatting app for todays standards, unlike Conversations it has swipe to reply, last seen, emoji reactions etc. The only issue is making account there, need to use other homeserver like @conversations.im if you don't want to pay for their @monocles.eu .
For IOS the only option is Monal.
For web I find conversejs better than mov.im as movim doesn't encrypt sent pictures in chat at all, and encryption of text messages is sometimes broken depending on how you set it up in settings of account and in chat, as it needs to be activated on both places, so conversejs is better, but less enjoyable UI than movim
Basically you need a server, which you host, pay someone else to host for you, or you join am existing server someone else hosts.
Then you find a client. There are a ton of clients around, but it's like picking a browser before Chrome ate the world. Tons of options and everyone has thier own opinions and information about them.
Conversations is a great Android client (also brings their own backend instance if you don't want to host your own), I don't know about iOS or server though.
It's overwhelmingly more of an outsider talking point than an actual issue in practice. There's a category of people that just says any extensible protocol must fundamentally have massive amounts of incompatibility, and brings it up every chance they can... and while that is technically always possible, it only happens in practice if clients diverge greatly. XMPP clients mostly work together much better than Matrix clients, from what I've experienced, as long as they've been actively developed at some point in the last decade. Which is by far most clients in use.
For Matrix clients I'm given to understand the issue is the lack of XEP equivalents. Either your server(s) and clients are all on the latest available version or you're SOL.
This makes third party clients effectively impossible since every change is basically a breaking change and the client and server are tightly coupled.
XMPP took it a step further and has feature segmentation by defining XEPs. This is basic minimum for defining an extensible protocol for client-server communication and has been for decades (maybe it was a new idea when XMPP first started). Notably, browsers use this same thing with w3c specs, which is why they keep working too. If you don't have this feature segmentation and negotiation, you don't have a functional open source client-server protocol full-stop (looking at you Matrix).
I think what XMPP has gotten better at is doing like with w3c and setting baseline minimum features, which has allowed more standardization of clients.
Don't get me wrong, I have been hearing about XMPP forever, and I would love to have an opportunity to try it. Unfortunately it hasn't happened. I have been forced to use Slack, Discord, I have had opportunities to try Matrix, Zulip, of course I have been using IRC for a long time. But XMPP? I may have installed an app, but I haven't had an opportunity to actually use it. Is there a list of communities there?
Then about it being confusing: you're right, that's an outsider point. Because I haven't been able to try it (again nobody ever told me "oh, this project is on XMPP, you can go ask your question with this app/website"), but I have been genuinely interested in it, I ended up on the official pages.
- Check the RFC list: https://xmpp.org/rfcs/#6120. The first one is more than 200 pages, the second more than 100. There are 5 "basic RFCs" and 19 "further RFCs" (whatever "further" is supposed to mean). There is no way I will even open them all. Conclusion: I have no idea how XMPP works, except that there is XML in the mix and a whole bunch of stuff around.
- There is a "technical overview" here: https://xmpp.org/about/technology-overview/. I invite you to have a look at it. Apart from the fact that it seems to use "XMPP" and "Jabber" interchangeably (I think? I'm confused), it kind of loses me at "Jingle", which seems to be a "multimedia specification" (does that mean it's for video?), and has a bunch of implementations, like "pidgin". Isn't pidgin an XMPP client? Here it's under the Jingle section. And then there are extensions, with a whole section just for "Multi User Chats": so the default is that there are no groups, and if my client supports this extension and the server supports it, then I can join a group? I gave up at "PubSub", I did not even read anything from "BOSH".
As a person who wrote his own IRC client, contributed to Signal and looked into the Matrix protocol (which seems more complex than I am comfortable with), I must say that XMPP is in its very own league.
My conclusion with Matrix was that nobody would ever want to write it from scratch, so there has to be some kind of `libmatrix` on top of which people could build. Seems hard in practice because it feels like it keeps changing.
I don't know how fast XMPP is moving, but I would hope that it is now stable. Is there a libxmpp that contains all the necessary features to write a client? Not clear to me. It feels like it's still a complex ecosystem where it depends on the client, and on the server, and on what you want to do.
> XMPP clients mostly work together much better than Matrix clients, from what I've experienced
I can only take your word on it: I don't know a community that is on XMPP, so I haven't had a chance to try. Matrix has been frustrating, that I can say.
XMPP has had less allure as "the new thing" since it's been around for a very long time. It was _the_ chat protocol in the 2000s when it started, and all chat apps used it (when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated). Vendor lock in started taking off not long after though, so Facebook Messenger (also originally XMPP) stopped interoperating and went fully closed along with a number of others, and the ones that interoperated didn't shift business models and disappeared.
None of that means there's anything wrong with XMPP, it just means it's not in the public mind.
IRC has been getting the retro nostalgia kick start, and it briefly came back to attention when Slack started as "wrapper" of IRC. In my experience IRC channels are used by about 50% of open source projects, even though it's abysmal for access on mobile devices, very unfriendly for users, and extremely limited in functionality. About 50% of those have a bridge to Matrix so the mobile access is at least somewhat solved, and there are some more usable client options.
It seems because you haven't seen people already adopt it, you believe it must not be good. I'd encourage some basic research for your own benefit so you can see how XMPP is way easier to setup and maintain, far more efficient, and more capable than the oddly more commonly used Matrix/Element. In fact, between the organization issues of the last couple years, everyone finally getting fed up with Matrix being brittle, unmaintainable, and extremely inefficient to run on a server, I would expect Matrix support channels to drop off very rapidly over the next few years.
> It seems because you haven't seen people already adopt it, you believe it must not be good.
On the contrary, I have been hearing about it for so long, I believe there must be something there.
But maybe there is something fundamental in the fact that because it is actually interoperable, it's a lot harder for it to get traction. If a client gets a lot of traction, it probably quickly gets tempted to leave the interop world and do whatever they want (and lock the users in). In other words, XMPP sounds like a success story of diversity, but the cost of that is that normies don't even know what it is. Similar to Linux in a way: if someone gets interested in Linux, the next thing they see is a gazillion different distros and people arguing about them (disclaimer: I have been a Linux user for 15 years).
Matrix is different in the sense that it does not look like a success in terms of diversity. Matrix is pretty much Element. And Matrix seems to be about converting everybody to Matrix: I have seen bridges to IRC that made the IRC experience so bad that people would move to Matrix. Not because Matrix was necessarily better, but because Matrix was killing the IRC experience.
In a way, I find it interesting that those "interoperable protocols" (both Matrix and XMPP) are all for diversity, as long as it is their protocol. XMPP wrote a blog post about the EU Digital Markets Act, saying something along the lines of "the DMA is a good idea, the only thing that they miss is that they should force everybody to use our protocol, XMPP". Matrix has a similar stance: "we don't consider it interoperability if we can't make it work with our protocol, no matter how much we destroy the experience on the other platform". Because the end goal is not really interoperability: it's interoperability under their conditions.
> when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated
Sorry to remind you, but this never happened. AIM and ICQ eventually interoperate because they were owned by the same company at that point. There was never XMPP federation in the mix here.
Yea, it was really only ever "libpurple let you easily use them all in one app nearly transparently, and many people did". Many did use XMPP under the hood, but afaik almost literally none federated.
Matrix is seemingly trying to leverage that memory, but "there's a bridge bot somewhere that you can run somehow, with extremely widely varying quality / integration smoothness" is rather different.
Pidgin is a universal client that supports many protocols/networks including IRC, XMPP, and has additional third party plugins from stuff like Discord and Slack.
I don't disagree, but whether you're even aware of the XEPs and how it's presented to the user, is a critical factor in viewing it as "confusing".
Gaim for example only even tells you about XEPs if you dig into the server settings, and then it shows a very good job of listing all XEPs from either the server or client and noting which are supported by each in a table if you're far enough down the rabbithole that this info is useful. But for a regular user they just log in and it Just Works (tm).
Yes I agree, apps should never mentioned XEPs. Most devs have no reason to even know about them, why would a user case? Some apps are built by protocol nerds and they like seeing the list. Maybe very hidden is ok but in general not something any user cares about.
How would devs not have to know about them? Say I want to write an XMPP-enabled app, how do I do it? Are there XMPP libraries that already implement all the required need protocols?
This is what I mean by "it needs a good client". It needs a single implementation that works consistently across platforms and has the features and UX people care about. The groundwork is there, and is better than Matrix. It's a matter of writing software to implement the useful subset of the specs.
It allows you to not having to define the point in time and neither the frame of the timespan's points in time.
Some languages allow to use that type of tense and it's somewhat a language gap I suppose. I have no idea what other languages or proto languages allow that tense though, but I've seen some Slavic and maybe Finnish(?) natives use that tense in English, too.
Maybe someone more elaborate in these matters has better examples?
[1] https://de.wikipedia.org/wiki/Plusquamperfekt
reply