100%. I think the article makes space for this, too. In 3, 4, and 5 the author describes the experience of bouncing off of something despite trying to like it as well as _thinking_ you like something despite not _really_ liking it. Both types of experiences resonated with me.
I think the key here is that you did try, you gave cooking and sports an honest chance, and it turns out that you're not into them. It doesn't feel like many people would put the effort in to really figure out if they _would_ like something that's initially uncomfortable or difficult. I think that's what the article is responding to - I read the overall thesis as "you might actually end up liking something that you don't like initially" rather than "you will like anything given enough effort".
Ah I can see that as well, I think you should discover new stuff all the time, but for some things you just know you won't like it, despite never having tried. Karaoke for me.
Will I finally be able to ask my car factual questions while driving? Right now android auto's assistant experience is way worse than on my phone or watch, so I end up having to use one of those (if it's important enough, otherwise I just forget).
Based on a cursory search, I get the impression they haven't solved the particular cleaning problem the author did (i.e. removing places that just have restaurants rather than actually are restaurants). In one case on my food & drink list I have a place that is very highly reviewed, but is actually a museum; I doubt the reviews refer to the restaurant specifically.
It is interesting to play with though. Thanks for the reference!
Apologies if my timings are off in this comment. They should be close enough to make my point, but it can be hard to find the actual dates.
I have run a Synapse server for almost 8 years, by my reckoning. For most of that time I have been a $15/mo supporter.
For several years, I had been hoping Dendrite would be released, along with a migration path to get my users over there. Synapse's resource usage is not great. I do run workers in order to improve performance.
I'm waiting for an official migration path because I don't want to have to migrate my community again like I did when we moved from Slack to Matrix. It takes a lot of work just to move people over, and you always lose a couple people, which is a serious cost.
Early last year I learned that they had put that on ice due to money issues. So there wasn't much hope of moving to a lower-cost Matrix implementation without a lot of headache. This makes sense. Building a homeserver implementation while maintaining an older one is expensive.
For a year or more we've had quite a few blog posts saying that there's not enough money and that large organizations join the Matrix Foundation. This makes sense. Those organizations have enough money to keep it going, unlike my small monthly donation, which doesn't really matter all that much in the grand scheme of things.
It's been quite a while since we've seen a new user-facing feature, and longer since we've had a selling point (which I could use to answer the question "why should I move to Matrix?"). It makes sense to prioritize functionality over new features, particularly when you've got a limited budget. But we still don't have some features which are very popular in Discord and Slack, like custom react images; these are implemented in other clients, like Cinny, but not Element.
Last year they released Sliding Sync in Synapse, deprecating the Sliding Sync Proxy which I had been running to support clients who wanted to use Element X (a new client implementation). I personally haven't switched since Element X does not support Spaces. Moving Sliding Sync into Synapse saved me some resources supporting those clients. It was a little hard to tell when it was safe to remove the Sliding Sync Proxy; I had to track a couple Github issues. Matrix used to have a public roadmap, but it's no longer updated, so it's hard to keep up with the status of different features in development.
After that they released Matrix Authentication Service (MAS), which is an additional service to deploy that moves the internal authentication functionality out of Synapse and interfaces with Synapse using OIDC. I haven't deployed it yet. They say it will eventually get rolled into Synapse, so I'm intending to wait for that.
All in all, it does not feel like the things I want, and (assuming I'm not a completely unusual case) that the community wants, are high priority for the Element team. Donations the size of mine don't make a difference for their budget. They're spending what budget they do have on refactors like MAS, which don't seem to impact usability (though perhaps they do if you have a massive homeserver). They spend time and effort supporting new features which make Element X faster (Sliding Sync) but have not yet implemented all the core functionality (Spaces) so there's not much reason to move.
I concluded a few months ago that our interests are not aligned any more and stopped donating. I know I'm not owed anything for my donations. I donated to support a project which I was excited about. This announcement, and that RAM graph which I will never see on my own server, makes me confident in discontinuing my support.
I do not feel like Matrix/Element values its community any more.
> After that they released Matrix Authentication Service (MAS), which is an additional service to deploy that moves the internal authentication functionality out of Synapse and interfaces with Synapse using OIDC. I haven't deployed it yet. They say it will eventually get rolled into Synapse, so I'm intending to wait for that.
They broke out synapse's authentication into a separate service, only to plan to roll it back into synapse later? There's probably more to it than that, right?
We replaced Matrix's custom authentication protocol with genuine OIDC: see https://areweoidcyet.com/ and the rest of this thread for details.
Therefore, we needed a basic Matrix-aware OIDC identity provider which could ship with Synapse and other homeservers in order to auth users (and optionally delegate to fully fledged IdPs like Keycloak). So we wrote matrix-authentication-service (MAS) in Rust, which is released as FOSS: https://github.com/element-hq/matrix-authentication-service.
This is released as a separate project because: a) it's written by a different team, b) it's intended to power OIDC auth for other servers than Synapse. For instance, https://github.com/element-hq/dendrite/pull/3493 is the pull to make Dendrite support OIDC via MAS.
In future, we may end up for admin convenience also bundle it by default inside FOSS Synapse (especially given Synapse is part-Rust these days) - so that folks running `pip install matrix-synapse` magically get OIDC-based auth without having to also run a separate MAS. However, this is a while off, and even then we'll continue to support MAS as a standalone service as the primary configuration.
(N.B. none of this has anything to do with Synapse Pro, and is an example of Element continuing to pour the majority its effort into FOSS work like MAS and native OIDC in Matrix...)
Firstly, thank you for paying to support the Foundation for so long and for sticking with Matrix & Synapse.
> It's been quite a while since we've seen a new user-facing feature
I'm not sure this is true, as you say yourself in the following paragraphs. On the Element side, we shipped Element X as the much-needed rewrite of the old Element apps. On the Matrix side, Matrix 2.0 is a step change in terms of instant sync/login/launch, QR login, native-OIDC, invisible encryption, etc. From an end-user perspective, my experience of Matrix has improved unrecognisably in the last year. I can see how this might feel different if you're stuck on the old stack.
> All in all, it does not feel like the things I want, and (assuming I'm not a completely unusual case) that the community wants, are high priority for the Element team
We've tried to prioritise usability, stability and performance over everything - including features. I'm sorry if this doesn't match your needs though.
> They're spending what budget they do have on refactors like MAS, which don't seem to impact usability.
Some of the usability improvements that MAS provides are:
* 2FA and MFA (which is frankly embarrassing that we didn't have before)
* QR login (for parity with Discord/WhatsApp/Signal "just scan this QR code to login")
* Refresh tokens, so that leaked access tokens expire rapidly
* Integration with password managers
* Password reset flows which work on all clients (e.g. password reset doesn't exist on the legacy Element mobile apps)
* Huge security improvements by actually following a mature auth standard (OIDC) rather than making up our own one. We've had some near misses on the old auth system for failure modes which OIDC fixed years ago.
> They spend time and effort supporting new features which make Element X faster (Sliding Sync) but have not yet implemented all the core functionality (Spaces) so there's not much reason to move.
Spaces is already there on the SchildiChat Next fork of Element X Android. We'll add it to Element X Android later in the year - but it's been delayed as the paying customers tend not to care that much about spaces (they just want a WhatsApp clone).
> This announcement, and that RAM graph which I will never see on my own server, makes me confident in discontinuing my support.
The hope is that the $ from Synapse Pro allows us to fund FOSS Synapse dev to improve the core perf & resource usage of FOSS Synapse - which in turn will reduce the RAM usage for everyone. (But massive-scale scalability will remain paywalled for now.)
To be clear: the reason small Synapse servers are slow is NOTHING to do with the workers being written in Python rather than Rust. We will use $ from Synapse Pro to speed up Synapse (and Matrix, at the protocol level) for everyone.
> I do not feel like Matrix/Element values its community any more.
Sorry. If we didn't value the community I wouldn't be sitting on HN trying to explain why we've done this. Thanks again for supporting over the years.
i ran a synapse instance for a couple years for private purposes, but at this point the ecosystem seems kinda captured by element. self hosting is a pain. in some places it's really hard to tell that mistakes in good faith were made or it's just intentionally complicated to keep "normal" people from running their own instance. Especially the whole worker setup was subject to change multiple times and broke my instance every. single. time. couple that with sparse, out of date documentation and the "pro edition" they now announced suddenly makes a lot of sense (from their perspective at least)
- They own Element, the by far most used client
- They own Synapse, the by far most used server
- They own dendrite, the only matrix server so far that even comes close to spec adherance with synapse, which has been strangled (as evidenced by the last release almost half a year ago [3])
Because everyone is running synapse, everyone needs to keep running synapse or risk losing compatibility with the federation.
This is not what the sales brochure for matrix read like. Like, at all.
Do y'all believe it's random chance that the official synapse docker-compose does not come with async workers? [1]
And now check out the terrible setup process for setting up the whole "workers magic" (which, mind you, is unavoidable the moment you have some bigger rooms joined) [2] - Like who on this godforsaken planet considers this valid even for 2022? Pair that with how easy to handle the base documentation is and things start to smell. They have the stench of trying to artificially create a moot by making it "too hard for non-pros".
I understand synapse and dendrite development need funding, but this is not the way to go. All good will towards Element as a steward of matrix I had is completely eroded by now and I assume that will be the case for many others too. Forks are bound to happen at this point and I'm looking forward to the ecosystem become more diverse again.
Oh, and did you know the Matrix Foundation is infact a UK based Inc. controlled by 5 people in 5 companies, of which 4 companies are residing at the same address [4] and the fifth has an odd interest in NFTs and other BS?
[2] https://matrix-org.github.io/synapse/latest/workers.html - note how this page is already marked as deprecated. Prepare for it to vanish altogether soon. You are not supposed to set up workers, you are supposed to beg element to run a decent matrix server
I feel the point is a bit subtler. We should strive for improvement. We should also understand that that takes more than the normal amount of resources to do something different and better & either commit to spending what's required or, if we can't afford to, use something already proven instead.
The half-done or broken improvements still get called "innovations" and give innovation overall a worse reputation.
> I feel the point is a bit subtler. We should strive for improvement. We should also understand that that takes more than the normal amount of resources to do something different and better & either commit to spending what's required or, if we can't afford to, use something already proven instead.
Indeed. I wish this point were articulated that way more often.
> The half-done or broken improvements still get called "innovations" and give innovation overall a worse reputation.
We fetishise innovation as an abstract concept, for good reasons because you cannot have progress without innovation. What we tend to miss is that while innovation is good, some specific innovations are terrible. This is particularly infuriating when they are re-surfacing old, solved problems. Looking at wall tiling for example (or the cladding that can be found in much of the Underground): this was a good solution to a common problem. Bare concrete walls have obvious downsides, which is why we don’t tend to use them in building anymore. Doing away with tiling or cladding sounds like an architect being innovative, but if the replacement does not solve the problem, it’s a regression. It will look modern and clean as long as it will be properly maintained, which is to say for about a year, and then it will decay the way concrete does. It will eventually be clad, or reviled as a post-modern monstrosity the way some bad brutalist buildings are today.
Innovation for innovation’s sake is cargo culting progress. This is giving innovation a bad name.
What innovation is left? Concrete has been around for centuries in modern forms - we can tweak the formula a lot, but still the same basic idea as when it was invented 100 years ago. Most of what passes for innovation has been tried before. Other things were not tried because anyone who understood the problem knows they are cannot be cost effective. Unfortunately the people who fund this cannot be experts in the field, and thus can easily be persuaded to fund things by scammers that anyone who really was an expert could tell you in a few hours of study are a bad idea.
The problem isn't that the politicians are not experts in construction - there is far too many things politicians fund for them to become experts in even a fraction of them all (they also have to fund medical studies, military spending...). The problems is politicians don't respect trained experts, thus don't keep people around to become deep experts, and in turn there is nobody around with deep technical knowledge to say what is a good idea. Or if there are such people around they are not in a position where they can be listened too, instead any scammer is allowed to present their pitch for "innovations".
That seems like the real problem with Spotify shuffle. The thing that feels un-random about it is that it plays the exact same songs over and over again despite the humongous size of the playlist. It's not that it plays the same artist, or that every once in a while you get a repeat song. Once you get one repeat they're all repeats.
I wish it would randomly pick the next song from the entire playlist whenever it changed songs.
Though as you say it might already be doing this now. I don't remember feeling like I'm rotating through the same 30 or so songs recently. But also I did start working around it, so I may just not be noticing.
The discount rate is doing a lot of work here. There is a discount rate such that we're not talking about shortsightedness. Getting it right is difficult. But as an example, how much would you buy an investment that pays a hundred dollars, guaranteed, next year for? Trivially, the discount rate includes at least the expected amount of inflation; it's not worth a dollar.
For assets line like IP you have to factor in how risky the returns are, how much investment you'd have to make to see them (e.g. making a movie), and overall strategy (do we want to be in that line of business).
All this to say - if you have IP that pays 10 million a year, you can value future returns on that IP in today's dollars. If someone offers you more than that to buy it, you should take the deal; you come out ahead.
As a Neovim afficionado - I think you lose some credibility recommending it as an alternative to VSCode and Sublime. They're different beasts. I imagine a lot of people would be immediately turned off if they were expecting a VSCode/Sublime-like editing experience.
I think the key here is that you did try, you gave cooking and sports an honest chance, and it turns out that you're not into them. It doesn't feel like many people would put the effort in to really figure out if they _would_ like something that's initially uncomfortable or difficult. I think that's what the article is responding to - I read the overall thesis as "you might actually end up liking something that you don't like initially" rather than "you will like anything given enough effort".