It is a bit weird to frame one of two competing protocols as the successor of the other, when the only data point for this assertion is that one is older.
Matrix has its de facto centralized server in Matrix.org where almost all rooms will have its data sent through because of accounts joining rooms. The servers have been too heavy/expensive for self-hosting that many end up relying on the big servers to use (maybe the Rust server will help, Dendrite?), but the “resilience” mentioned is a big cause for this expense (similar issues with Mastodon). JSON isn’t superior to XML--it can be in some cases but it’s not without drawbacks; experimental EXI could help with the size. XEPs are an ad hoc unified spec, and the buy-into-or-not nature has some advantages where it’s easier to experiment and fallbacks are common even with fragmentation. OMEMO isn’t perfect, but it does cover multi-device encryption and carbons work to get message history.
I like Matrix. But I don’t think it’s the only or best solution despite all of the current hype; the XMPP solution should be looked at more often. XMPP offers additional flexibility as well not being limited to just a chat/communications platform where folks use it for presence, UnifiedPush, etc.
Its not to big to self host. It uses maybe a bit to much memory but anybody that has a real server (more then a Pi) can host it mostly fine. And many do.
Most federated system have one large server that has many users.
I hosted an ejabbard server on a 2014 smart phone for a while earlier this year. ejabbard & Prosody are reasonable to host using DDNS on a home network on just about any hardware which is much more accessible and decentralized than needing a “real server”.
There's many servers on matrix and even synapse isn't that heavy.
What bothers me the most about xmpp is that only the barebones stuff is in the main spec and everything else is in extensions which creates a complex maze of support by servers and clients alike.
I've used both but I like matrix the most. Its bridges also seem the most mature.
Being barebones is a part of the selling point for an eXtensible platform though. ejabberd came with really good defaults, and Prosody only a little painful (though most of that could be chalked up to DNS being a pain + Nginx behaving unexpectedly). If you need something more turnkey, Snikkit can be useful if you believe Docker is a good idea.
> Being barebones is a part of the selling point for an eXtensible platform though.
Understood but as a user I don't want core functionality like history to be hidden behind extensions which may or may not be supported or need additional components to client or server.
As a user (and home server operator) I found that Matrix+Element gives me a much better user experience with much less fuss (though I admit it was more than 5 years ago when I last ran ejabberd). And the bridges are amazing, just what I needed. Because Matrix is not very useful until everyone uses it, for the transition there are bridges.
I don't really care about the underlying architecture, I just want it to easily provide me a modern chat experience.
I won’t disagree with this. It could be a part of the main spec, but there’s some novelty knowing you could do a ‘complete’ server or client in a day. There are certainly different modern expectations than compared to IRC. Compared to the OP, barebones XMPP is much closer to a ‘simple chat’.
> bridges
XMPP + libpurple were trying to do similar things. For a hot minute everyone, even the like of Facebook Chat and whatever Google’s chat was named at the time, was using XMPP til they all decided to go for a proprietary option and users had the option to chat from anywhere with anyone. That doesn’t discount Matrix for doing something needed now. Proprietary chat lock-in runs in cycles. Here’s to hoping they don’t adopt & abandon Matrix.
> I won’t disagree with this. It could be a part of the main spec, but there’s some novelty knowing you could do a ‘complete’ server or client in a day. There are certainly different modern expectations than compared to IRC. Compared to the OP, barebones XMPP is much closer to a ‘simple chat’.
Novelty sure but it's not really complete in terms of what a user expects. I still use IRC a lot too but with a client that provides all the mod cons I need. Also, nobody writes a protocol handler from scratch anymore. People writing a matrix client will simply use libmatrix.
There's just the reality that "simple chat" akin to ICQ in its early days, is just not what people want anymore. It's not a benefit anymore IMO.
I think the XMPP community is really too focused on architectural cleanliness than on offering the user what they want. Which is their prerogative, sure. But it's mine to choose the chat network that suits me best. This is how I moved to Matrix.
> XMPP + libpurple were trying to do similar things. For a hot minute everyone, even the like of Facebook Chat and whatever Google’s chat was named at the time, was using XMPP til they all decided to go for a proprietary option and users had the option to chat from anywhere with anyone. That doesn’t discount Matrix for doing something needed now. Proprietary chat lock-in runs in cycles. Here’s to hoping they don’t adopt & abandon Matrix.
Yeah I know, they killed federation, I guess mainly because of marketing. If google chat users can reach facebook chat users there's no need to sign up for facebook chat, thus less data mining for facebook, and lower numbers in their growth hacking charts. Keeping users in the walled garden is a goal, not a side-effect.
This is also why I dislike Signal so much, they even ban other versions of their supposedly open client. I'll never adopt that as a whatsapp replacement because it's simply no better in terms of lock-in. I don't want yet another walled garden. Signal solves one or 2 problems of whatsapp but for me to adopt something as the be-all-end-all chat app it will have to solve all or at least most of them.
It doesn't really matter if the third party apps adopt Matrix and stop federating. It won't be any worse than it is now. I'll just bridge where needed.
None of that were problems that stopped XMPP from being popular. The ones you mentioned are problems nerds had with it, not normal users. Except "unified specification", that's a big one
It was simple: UI/UX experience:
* each server supported different set of features
* each client supported different set of features
* some of them (like gateways to other chats) were "generic" enough that power users were needed to set them up, even if they worked extremely well
* Most chats were "text-mostly" with shitty html subset, which was just worse for power and normal users alone compared to now-near-standard "markdown + reactions"
Will you get your chat history on given combination of client and server ? Who the fuck knows
Will you have direct data transfer work ? Who the fuck knows
Can you share file to a group chat ? Who the fuck knows
"Oh look markdown is popular, lets IMPLEMENT SOMETHING ELSE THAT'S SIMILAR BUT INCOMPATIBLE" https://xmpp.org/extensions/xep-0393.html and other great XEPs... I swear whoever is running that is smoking crack
And the XEPs. Millions of them. There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site.
XMPP is absolute mess and mountain of design by committee
482 of them. A XEP is how someone proposes a feature, and how the community collaborates around the protocol's development. Many XEPs never gain enough traction to be marked as "stable", and they get automatically deferred after a year.
This means out of the 482 XEPs, a much smaller number are actually required to implement working stuff in XMPP.
Hopefully this solves the common misconception, which you seem to have, that you have to implement every XEP. Some aren't even dealing with protocol changes, some are only informational, and some only pertain to client or server features.
> There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site.
False. We publish annual "compliance suites" which contains an array of features and two compliance levels for each ("core" and "advanced").
> There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site.
Yes, there is. But your entire comment is based on years-old view of what XMPP was
I'm going to reply to some of your points because they're misguided:
> resilience against servers going down
The matrix model and the XMPP model are different. They solve orthogonal problems. Even the matrix people say it. That's like saying emails are better than github for collaboration because they are resilient against servers going down: it's true, but it's a different model. Not suitable for everyone.
> resilience against malicious federation
Wait for matrix to be taken up by big tech companies, you'll see spam flooding. I don't welcome it, but it's all about economics
> Json instead of XML
This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do.
> > Json instead of XML
>
> This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do.
Can you elaborate on this a bit more? Specifically what can XML do that JSON can't?
I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages.
I even consider some things in XML (or at least in common implementations) to be nuisances, like collapsing elements into properties, or some accepting either or both without a schema, and I'm never sure what the precedence rules are. Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too.
Put XML inside XML, which is most useful for wrapping. Extensibility is built-in, so any parser knows it has to deal with namespaces; it doesn't depend on the flavor of the library.
> I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages.
It's not necessary for transporting messages, but both protocols go way beyond messaging. How do you send an invite for a party and a fallback if it isn't understood by the other side ? In XMPP you use namespaces; in JSON you have to define yet another schema that will only be used by your app and everyone else must copy it.
> Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too.
I'd like to see actual numbers of real software before believing the parsing speed even matters. A matrix server has to sync with dozens, sometimes hundreds of servers, some of them being extremely slow. I don't think the speed of parsing changes anything.
Plus, the spec is simpler indeed, but it is too simple. Namespaces solve a real problem, it's a mistake to not have them.
That hurts a lot, I got in way past the point where it was acquired by amazon, but the forums were always a very nice place to interact (with its lots of weird and single-focused people, as every forum, that gives it charm). The reviews for most cameras made in the last 20 years were invaluable and very detailed, although lately they certainly struggled to maintain the quantity of content they put out in the past.
I cannot imagine that cutting the maybe 30 people (tops) required to maintain the site and push content will make a difference in Amazon revenue; but removing this great online resource is sure to sadden thousands of users.
Former DPReview News Editor (who left after getting news of this back on January 18th) here: There were 8-10 members of the editorial team that were full time and a small group of freelancers. Add in about 8-10 more devs, who cycled in and out for the most part. So, 15-18 people, tops. By my rough math once, our entire operating cost for the year was about 10-12 minutes worth of Amazon revenue.
Worth noting this math is based on estimated numbers from what I roughly knew people’s salaries were and what server costs were roughly estimated at. I had no first-hand knowledge of the numbers, as I wasn’t allowed to view that info as a contractor.
Is it true that they're not going to sell the assets, and just shut everything down? If I had connections to an investment banker, I'd be trying to see if there's an in with Amazon...
I wasn’t privy to that information even before I left (Feb), but from what a few people who were/are privy to that information have told me, it doesn’t appear as though Amazon is at all interested in selling off the IP. So yea. Just shut it all down. Which is a fucking shame.
I've seen a few of these bonehead decisions in my career. Typically it happens because "MBAs are eating the world" -- someone with the idea that the number of things you have needs to be made smaller makes a ranked list of all the things in their area. Then they run "head -7" on the list.
I saw this happen long time ago when a company I worked for decided to close a product division because it was the fifth most popular i
the company. The people working on that product left, formed a startup, did the exact same thing and made $$$. Today the product category is a tens of billions industry.
It might be intentional then. Instead of having that content out there again where they will presumably have to pay affiliate commissions to the new owner, they must've calculated it's more profitable to just get rid of it.
From their announcement, that appears to be their plan. They said they will keep the site up for an limited amount of time. It's speculation on how long "limited" is. Months, years? There might be some clues with how quickly they shut down alexa.com "In December 2021, Amazon announced that it would be shutting down its Alexa Internet subsidiary. The service was then discontinued on May 1, 2022." which would put it at 5 months.
5 months seems not much time for a platform like this. I recently bought a lens that has been released 3 years ago; a gear review written today could provide useful information for much more than 5 months.
I wonder if the problem is they are shutting down 50 other sites that are similar to this, for other types of products. Cutting 1 doesn't make much of a diffference but cutting 50 certainly does.
"Pandemics are known to cause widespread disruption, illness and hardship as we have experienced since 2020. An endemic means a disease is spreading in a community at the normal or expected level. A pandemic begins to shift to an endemic once the disease becomes more stable and manageable."
COVID has mostly moved from pandemic to endemic (like the flu).
> But other than netting a hefty fee for the lawyers who bring the suit, what is the endgame, exactly?
Pay people whose works you want to extract value from, it is that easy… Unless the whole point of this "AI" bubble is to create monetary value for the companies and their shareholders without being held accountable. I do not mean that creating, configuring, tuning a model, or even compiling a massive dataset is not work, but it is the tiniest fraction of the work that went into whatever is present in the dataset.
> also, for software authors, prohibiting ML training would be antithetical to the Open Source Definition. So that probably won’t work.
A-ha, at one point I hope even AI zealots will be forced to acknowledge that the process is creating a derivative work and sure, train on my FOSS sources all you want, but the end result will need to abide by the licenses of all the sources browsed (have fun).
> As the tech industry celebrates the frothy emergence of machine learning in a time of economic doom and gloom, let’s hope this nascent field doesn’t sink because of the copyright iceberg looming ahead.
I am sorry to break this to the author, but not all fields and jobs need to exist. I have not seen much net positive from "AI" to society as a whole so far, with even less exciting things on the horizon.
Trying to legislate model training is impossible and stupid. At worst some copyright holders will sue a company because a model is biased and produces close-enough replicas of something under copyright. Model builders will respond by penalizing models that reproduce copyright images too closely, and better curating data sets to avoid bias, at which point the issue will be moot.
I don't want anybody to feed any of my work into a model at all without following all the terms of the licenses of my work. If my work is used to generate, via a computer program, a derived output, then you need to follow my licenses.
People keep pretending that AI is the exact same thing as a human learning, but it's really a lot more like a fancy compiler with highly non-deterministic output. AI is not a human.
I wouldn't be surprised if these large language models have an interior life that is more rich than many humans I've met who barely seem cognizant of their surroundings.
Quite the opposite. I got covid in march 2020 and since then I have mostly WFH, and been careful about masking with efficient gear (N95 and up) indoors, and I have not gotten sick once, whereas previously I would be out one or two times a year for a week each at least.
I do have a perpetual runny nose and some coughing from time to time, but nothing that would qualify as an illness (and I had that before 2020 as well, possibly thanks to inhaling too much tear gas years ago).
There is no scientific basis for this assumption (the idea that you rake in immunity "debt" by not getting sick, leading to worse symptoms /when/ you get sick).
It's not "immunity debt" but rather that immunity for seasonal diseases is not permanent - you lose it if you don't use it, basically, with "refresh period" about the same length as the disease cycle.
I don't have citations handy, it's just something I've seen mentioned here and there some months ago, as a possible explanation why after 2 years of lockdowns, many more people seem to catch the common seasonal diseases.
It seems plausible that the immune system requires stressors to function well, and the absence of stressors may reduce immune system "strength". Selye's general adaptation syndrome seems applicable here as a first approximation. Muscles atrophy from disuse. Why not also immune systems?
The immune system is never dormant. It is constantly engaged. We don't live in a sterile environment, don't eat perfect sterile food, don't breathe perfect air, etc. There are multiple aspects to our immune system, and a lot of them are being stressed daily.
Dynamic range is better on the phone, but otherwise the DSLR has sharper edges, less noise, nicer colors, and is less mushy (but that is possibly due to the "AI processing", so ditto about the "real" image). That said, noise reduction is usually more advanced on phones, and handheld with a kit lens at night with high-contrast zones is kind of the worst scenario for DSLRs (hopefully it was a stabilized kit lens at least).
You can read the words "Hotel Platinum" on the phone photo. And it's blurred and "mushy" on D5500. And the phone had additional glare from an oncoming train, and it still pulled out things out of the dark.
Depends on what you need, of course, but for most people the photo from the phone is superior.
Even with less outdated cameras (e.g. the last high-end APS-C from Nikon, the D7500), HDR bracketing is much worse than most mid-range phones from the last 5 years. And assembling them after manual bracketing in post-processing is also not great. Nikon HDR creates halos, doubling, even on relatively fast shutter speeds.
That said, I don’t have the experience of phones being "good enough", and even my Sony RX100 (edit: was "RX1", my bad) first gen which is quite old is out-performing 99% of the smartphone market in picture quality on a good screen, if you exclude HDR.
Sorry, I meant to say "RX100", it is now corrected. Yes, even with the improvements in sensor technology, glass, and post-processing I don't see a phone reaching RX1 quality anytime soon.
