(I’ve quoted snippets for brevity). The restaurant analogy kinda breaks down here. It’s like you are sitting at 2 tables at the same time, and a larger ‘aggregated’ restaurant with more people to celebrate with. What you are saying can be true, but also wholly depends how things are implemented.
While the ActivityPub RFC topic and @hellekin’s use case put individual people in full control, in my description above I leave community structure fully in the hands of community staff. They make partnerships with other communities, and are possibly only able to share cross-sections of their community based on mutual consent.
I thought doing so would be more in the interest of Discourse (the company) as well as the community managers who put in so much effort to build their identity and member base. I.e. it would be more of a business case. So staff would be still in full control, and also take care of keeping the constituent community organisation comprehensive and intuitive. They are the “editors of community fabric”.
If you’d allow full freedom to Discourse users to fill their empty ‘portal’ with forum content from everywhere, then you’d get a wholly different community dynamic. The use case has value, for specific cases, but it is a completely different one than the ‘staff keeps control’ use case. Of course, all shades of grey in between are also possible.
Yes, know about them and I love the idea of OpenBazaar as a decentralized marketplace, yet it is the cryptocurrencies that withheld me from checking it out. It is a trust issue. For many people that may have also held them back. But other than that it is the enormous network effects of established Big Tech that makes it very hard for newcomers to make an entry, where they launch a new service, advertise it on sites with millions of daily visitors and be able to operate at a big loss until the thing finally takes off.
Yes, I agree with that. It is why I did not focus on the “full freedom”, but rather “staff in control” use case, as described above. Where ActivityPub support adds a USP to Discourse as a product for community managers, the paying customers. Well… if they choose a cloud-hosted subscription, that is.
In that regard Discourse (the company) might make subscriptions more interesting by providing value-added services, like a discovery and match-making service where community managers of different communities are actively looking for partnerships and cooperations to enrich their (and implicitly each other’s) communities. The service may be accessible to anyone, or only to customers on a paid plan.
Should they want to? Why should that be the goal? ActivityPub as a protocol allows many different applications in many different domains to interoperate at any level. Each project / app / product will pursue its own goals and, for commercial software, its own USP’s.
The first part is important. Choose your federation wisely. Full federation should never be the goal if you lose all your identity as a product by doing so.
First of all there’s a difference between ‘federation’ and ‘the fediverse’. If you build federation using ActivityPub then you can build it any way you want it to work. If you build with the objective to integrate with the Fediverse, then there’s some established de-facto standards how things work. A fediverse-wide ban on the user level is not possible, and bans on specific instances are based on decisions of each and every other instance’s moderators, and configured in block- and allow lists. These lists are often shared (like ad-blocker lists) and may lead to certain instances becoming entirely blocked across the fediverse (‘they are pushed to the fringes of the fediverse’).
A good video that explains the concept is:
Like forums, each federated instance in the Fediverse is moderated. And I think that is a good thing. There’s still full freedom, because you can spin up your own forum / server instance without moderation where anything goes. Others have the freedom to block you based on that.