@lari @petri the real issues for me on #Mastodon versus #BlueSky:
1) Onboarding difficulties killed a lot of initial interest. That has improved a bit, but there are still issues (empty feed problem).
2) Desperately poor UX in parts. E.g. the whole missing replies / missing posts is unresolved and extremely problematic.
3) Related to the above: development speed. Maybe it is underfunded, or there’s resistance but many issues have been sitting around for years.
@Setok With regard to this, realize that a lot of the problems come out of engineering decisions made long ago that would be very difficult to change course on at this point.
It's not merely a matter of throwing programmer time to tweak some UI functionality.
It's more akin to deciding to build a car and later on complaining that really you wanted to fly but this vehicle doesn't do that.
It's pretty hard to change course at this point without starting over.
@Setok so I lost track of that thread, and then I found it again and realized I hadn't finished it.
I see that the thread really went on to focus on developer attention and funding, but now let me emphasize that I'm saying there are core problems to ActivityPub that can't be fixed with just some more developer focus or funding.
AP was to its core built around instances, not users, and so many complaints that people have come directly from that design decision. It's not like a developer can just change that. To make AP center on users would make it an entirely different protocol.
At that point you might as well just use one of the alternatives that's already doing that.
This is the model that the entire system is built on. No interface changes are really going to fix it.
And this isn't even getting into the major efficiency problems with the model, this is just what is conceptually required.
@Setok right, I don't think federation is itself the problem. It's how the federation was designed around here, with the big focus on http-like requests between instances, inboxes and outboxes, and the rest of the core design.
It didn't have to be this way, but to change it now, to do things like moving content distribution to other layers of the communication protocols that could better address multicasting for example, would give you just a completely different system.
@Setok that's right, some complaints are that the Mastodon/UI level and some are deeper.
Some are solvable and some not.
BTW, if you weren't familiar with the history, some things like the lack of quoting in Mastodon were due to the strong personal opinions of developers who thought they were simply bad and should never exist here.
So that's another issue: sometimes it's not lack of funding or developer resources. It's developers intentionally choosing to leave out functionality they don't like.
@volkris @Setok @lari If users / devs are not free to experiment and innovate it tells a lot. Wordpress is one of the success cases in building an ecosystem on top of their core product that is open sourced.
Opportunity costs matter. Is it worth the time and effort try to fix something or build something else?
The freedom index (and almost the chronological order except with Threads):
Nostr > Bsky > Mastodon > Threads > X
@petri and FWIW, the instance I'm on, #qoto runs a modified version of #Mastodon where a developer did add features like #QT. So there is some experimentation going on here.
It's just that so long as the mainstream interface to the system refuses (or declines) to adopt such solutions, well, network effects.
@volkris @lari @petri even with those premises, I believe many problems are solvable. In fact some problems (empty feed problem when joining / algorithmic options) don’t even need protocol changes, pure instance code. And I believe ActivityPub always supported quoting in the protocol.