Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm

community
1

In ActivityPub Support: Phase 1 RFC I outlined an ideation exercise to evaluate the business case for having ActivityPub support in Discourse, and think beyond a MVP as-if Discourse was built from the ground up with federation in mind:

So hereby I will kick off the ideation with some brainstorming and without taking technical practicalities into account given current codebase. I realize there are many ins and outs and edge cases to all of this. This is a vision of what native federation support might look like. Here goes…

Community has no boundary

pexels-pixabay-262488
pexels-pixabay-2624883648×2736 924 KB

(Photo by Pixabay from Pexels)

We all share one planet :wink: intermingling in complex social structures. Why is a Discourse community restricted to a single forum?

I am admin of Humane Tech Community (HTC) and we cover a broad range of tech-related subject areas, having (sub)categories of “Freedom > Privacy”, “Alignment > Ethics”, “Alignment > Standards”. Too broad maybe, and many other Discourse forums exist that specialize on these categories, and in that field do a better job than we do. But for people interested in getting an overview of the entire field of humane technology the broad positioning makes sense.

Federating categories

What if I could federate our “Privacy” subcategory with e.g. the “Blog Posts” subcategory of the PrivacyTools forum? Maybe to only synchronise topics in one direction - as HTC’s privacy subcategory is broader in scope - where topics created at PrivacyTools appear on the HTC forum, and our members can interact with them. Topic posts on HTC forum are then transferred back to the topic at PrivacyTools and vice versa. The topics on both forums are kept in sync. Maybe I even want to one-way synchronize multiple PrivacyTools subcategories to “Privacy” at HTC. And why not sync with different privacy-related communities in a similar way.

Another example. Both the Feneas and SocialHub share a top-level “ActivityPub” category. There’s overlap in these, duplication, members from one community unaware of what is happening in the other community. This is an opportunity where “ActivityPub” is candidate for bidirectional synchronisation, where each forum then contains the same topic lists.

Federating tags and individual topics

Same can apply for tags, where a particular tag is configured to be federated. This might be e.g. set up such that any topic with #specification tag in SocialHub is federated to “Alignment > Standards” subcategory on HTC.

Topics may also be federated on a case-by-case basis, triggered by a toolbar command, where you specify the target forum to federate to, and maybe also select the remote category that the topic should appear under (i.e. the forum Category list is also federated for remote browsing).

Member mentions and profile views

When a topic is federated to another forum, any mentions within need to be adapted to reflect where the member resides. My @aschrijver handle at HTC might appear as @aschrijver@humanetech on the SocialHub forum after synching.

Since I am also a user on SocialHub in my profile settings I might connect the accounts, and after a verification this means that in the synched topics my local account handle can be shown.

When clicking a remote handle or member avatar the profile card of the remote forum is displayed. When clicking again to see the profile summary, it may show only the activity metrics on the local forum that resulted from synched topics interaction. Alternatively, and more interrestingly, it would show summaries from all known forums that are part of the federation config. E.g. I would then be able to find out that the response came from a very active, expert member on the other forum.

Direct messages and notifications

DM’s would be possible across all federated forums, not just locally, by tagging/mentioning the remote member in the DM. Other than that there would be no difference in the way that DM communnication takes place. It works the same as current local-only DM’s.

From all the federation stuff described above arises the need to also federate notifications. If I respond to a remote member’s post, like their post, or mention them in a synched topic thread, a UI notification may appear in the remote forum to notify the member. Email notifications are handle by the remote forum as well. However, if the member has linked accounts on both forums the notifications might be coming from the local forum where the interaction first took place.

Single sign-on

Note that in all the functionality described thus far, there’s no need to have SSO. A remote member does not have automatic privileged access to another federated forum. So what if they are mentioned in a one-way synchronised topic thread? In that case they will receive a UI notification and email coming from their own forum instance, and when clicking that are directed to the other forum (maybe in a new browser tab) where they can just view the topic. If they want to respond they have to first sign up and link accounts, to be able to respond.

Note that SSO is a tricky thing on the Fediverse, that has no good solution yet. But for Discourse-to-Discourse federation the SSO facility may be much easier to implement. If there were SSO integration, then clicking the notification might open the topic in-context within the current forum (as a ‘remote view’), and allow the member to interact with it seamlessly.

Federation management and complexity

This whole use case is described as-if Discourse was built from the ground up with federation support built-in. If all this is implemented it touches nearly all features of the product. Unlike the use case that started this thread - for FB-like personalized feeds - the federation here is carefully managed by forum staff, not on the whim of individual members.

Much of federation config is admin-only stuff. It should be done strategically and with a good plan, so as to keep the community organization and content intuitive and logical. The federation set up is built gradually over time as part of community-building workflow, not something that is casually added.

Interoperability

Of course this vision of ActivityPub support need not be restricted to Discourse. Any compatible software project could become part of the distributed community fabric. For instance forem’s open-source community building software and loomio collaborative decision-making platform, both of whom I just pointed in the direction of this post. But Discourse has the opportunity to take the lead in all this.

Fediverse integration

All of the federation support so far was limited to the forum/community business domain, but with ActivityPub integration interoperability can now expand to embrace the broader Fediverse, enabling numerous exciting business cases. Just to list some that randomly pop up with me now:

  • Announce forum posts fediverse-wide with toots on the Mastodon / Pleroma microblogging platforms.
  • Embedded images are auto-uploaded to PixelFed and served from there (nice for e.g. Blender communities).
  • Date/time toolbar allows setting up a full Mobilizon Event facing the fediverse, with full RSVP features.
    • Integration is 2-way enabled, where Mobilizon Discussions on the event are actually Discourse topics.
  • Create PeerTube topics with special video features, where the posts are the comment thread at PeerTube.
    • Same holds for Owncast if they add AP support (see this issue).
  • Your published topic automatically becomes a Writefreely blog post plus comment thread.
  • Embed parts of your forum into Nextcloud as an app via its ActivityPub support.
  • Integrate podcast features via Funkwhale (see recent video about podcasting support).
  • Obtain profile info from Flockingbird, professional social network under development (LinkedIn-like rolodex).

And look at the ever growing number of apps on the ActivityPub Watchlist and let your fantasy guide you :smiley:

Consequences

Forget for a moment all the technical hurdles and obstacles and consider what having this means for Discourse as a product. Or rather as Discourse no longer being ‘just-a-product’: Discourse has become a distributed community fabric.

Forum staff are no longer just that. They’ll adopt a much broader perspective to community-building. Both the community and community content exists all across the Discourse fabric. Staff will be actively looking at other Discourse instances, approaching their staff to forge partnerships and create interesting federation designs to slice and dice their community organization and content to be most interesting for the community member base.

The community members themself are also much better served. More interesting content will flow to their forum ‘portal’ and the forum will be more active than if it were just a local thing. Community members will be able to discover and interact with members of other forum instances all across the fabric. In fact the community boundary has been removed: Community has no boundary.

17 Likes
2

To be fair, I only lightly skimmed, however: What problem are you trying to solve with this fabric idea?

2 Likes
3

First of all I depicted a whole bunch of possiblities without restrictions, as input to the brainstorm. But personally I have two problems I’d like to see improvements in, one as a general community member, and one as community facilitator (staff on currently 5 forums, where I cross-post now and then):

  • As community member I have accounts on 15-20 Discourse forums now, juggling accounts (some forgotten) and passwords, and checking popular ones in a carousel-like fashion, site by site. These all happen to have many overlapping content areas, given my interests. Now if you’d ask me to join your great forum on my favourite subject, I’d still be very hesitant to do so and create yet one more account.

  • As a community facilitator I have a similar, related, problem. My community may be small, and you may decide to join that other community with content on similar, partially overlapping subjects instead. Or vice versa. Or you may not even know about the existence of that other great community (maybe I as community facilitator know it exists, but would I dedicate a pinned topic to inform my members?).

With the federation support in place there’d be a win-win for community facilitators to cooperate in partnerships and sculpt forum organization for our consecutive audiences and benefit from each other’s strengths. Concretely this would entail:

  • Ability to provide higher quality content by selecting most appropriate sources to federate from.
  • Larger member base - the aggregate of the federation - and hence more people to have interesting discourse with.
  • Higher activity levels in all forum instances participating in the federation, which helps to retain recurring visitors.

Three aspects - quality, quantity and activity - that are key to any successful community :slight_smile:

8 Likes
5

I agree, this can be a real pain. I solve this problem by adding the RSS feed from the Discourse communities, and having the in-built weekly digest emails enabled.

4 Likes
6

I just recently finished Niall Ferguson’s “The Square and the Tower” which is about is about the influence of social-networks (obscure and informal social-connections between individuals) throughout world history. It’s a far from perfect book, but it consistently reinforces your point that “community has no boundary”. Distributed networks are more resilient, innovative, and egalitarian than hierarchies; Discourse describes itself as “a from-scratch reboot, an attempt to reimagine what a modern Internet discussion forum should be today , in a world of ubiquitous smartphones, tablets, Facebook, and Twitter.” Unless Discourse’s ambition is to be just the latest and greatest forum software for a time, ActivityPub integration is the clear way to seriously challenge Facebook, Google, Twitter, et al. and overturn expectations of what an online community can be.

8 Likes
7

@aschrijver Sure, I personally love the ideas and thinking.

This seems to be achievable quite “easily”. For the accounts part, you could use a main Discourse which would act as a SSO provider. Other Discourse forums would just have to join the system to build a central user base: Your username is reserved for you across all the Discourse using it. Ideally, forum admins/owners would join at the creation of their forum. It would be possible to join later, you “just” would have to solve all the double usernames showing up at that time: The admin would have to make his users change their username when the username is already used on the system.

For the partnership part, plugins using Matterbridge and/or Discourse API should be able to do everything. There would be some plugin development and refining to do here.

Alternatively, for new forums, there may be a solution for a “multisite” approach: Create categories on one main Discourse (could be the same as the SSO provider for the above idea), and one category = one “forum”. By adjusting a few things, you could “lock” a little people inside the category, remove the mentions to the main “categories” and repurpose it as being different “forums”. By activating sub-sub categories, each forum still has 2 levels of categories. There are adjustments to work on, but this enables directly a common userbase and inter private messaging (you’re on the same Discourse!).

You can combine the 2 approaches: Having forums hosted on the main Discourse and external ones linking to it. I think that translating your vision into reality is possible quite easily. I’m potentially willing to work on this if there is an interest (I would need some help, though). I’ve registered the domain webforum.link which can be used for this.

Note (after seeing previous post): ActivityPub is something “open”. The above ideas would be far more “closed” and restricted to Discourse forums. It wouldn’t be as easy to join, either.

3 Likes
8

@aschrijver , following on our post exchange in ActivityPub Support: Phase 1 RFC - #50 by Mevo and also trying to take things here (this is a more appropriated topic):

There is one thing I found pretty interesting lately: Some folks created a free and decentralized marketplace called Openbazaar. The idea was basically to have something totally open and where anybody could put anything for sale, without any possibility of restriction or censorship. It’s based on cryptocurrencies for payment, and there is a possibility to review sellers and a system of moderators to eventually arbitrate transactions which may go wrong/have a problem. NO FEES on transactions whatsoever, the thing is 100% free (there would be a small fee for the moderator needing to intervene if that may be the case).

I mean, on paper, this thing is fantastic, IMHO. Yet, it never really took off. On the other hand, Ebay or Amazon, which take quite some fees on every single transaction, run very well.

The point is that having someone who controls something, who has an incentive to make it work because they profit financially from it, and who will invest towards this goal, usually make it work better than free, open and noble ideas. It may be very sad, but in practice, this is what seems to happen in real life.

Did Mastodon take over Facebook and Twitter? Will it ever? Users don’t seem to be fed up with the amount of ads they eat on facebook.

Anyway, it appears to me you didn’t take in consideration that aspect in your view about federation. So, here it is for you to maybe consider (or at least know about it). It doesn’t mean having the option to federate things, or enter partnerships, isn’t a good idea. But going “full federation” may also remove the appeal of running a software, which only becomes a “node” and isn’t something you control anymore. It’s quite different, at least.

1 Like
9

The progression of usage of a platform is not linear. Take the example of Signal: Snowden said “use Silent or Signal”, and the app progressed. It stayed as a niche so. A Gafam makes a bad communication and Elon Musk says “use signal” and hundreds of thousands of users come because they synchronously benchmarked the same criteria and the landing app responds to their need.

Some users might have left twitter and facebook recently, without much media coverage, because the main provider of reactions in their feed has seen his accounts deleted.

The more the system goes chaotic on social media, the higher the probability that users synchronously engage in a massive “uninstall app1, install app2”.

1 Like
10

I’m not sure the Signal example is really comparable. Here there is a clear added feature, and a WHY people should use it: “Use encrypted communication so that what you say remains private and nobody can listen to it”. It would be moving from unencrypted to encrypted.

But when moving from a “closed” and “isolated” platform to an “open” one, if we think about “full federation”, does it really bring something to users? Does it really add a feature for them? Some may say yes, as they see how they participate to several communities, and it could aggregate this (I do understand how burdensome it is to log to xx different communities)… But at the same time, if all users were moving to one “closed” community becoming dominant, it would pretty much be the same for them. I’m not sure they would see the difference, or want the “openness”.

People care about the content, the interactions and so on, but does it matter to them how it works technically and who controls it? The move to “federation” is somehow a move from COMPETING to SHARING for communities. They may be friends with each other and be ok to send users from one to another, but they still compete when they’re closed.

Your second point is interesting: Would some “federation” prevent bans, account deletions and censorship? THIS may be an added “feature” for people. Currently with ActivityPub, I guess you can get banned from individual sites, but you can continue to post to the rest of the federation… as long as the site you registered to doesn’t ban you? @aschrijver , do you know how that works? (I don’t know ActivityPub well enough). Are you registered at some federation level, or you’re registered to one of the site belonging to the federation? Can you get banned at the federation level? Or that’s impossible? (supposed to be impossible?)

@jibe-b The question wasn’t really going from app1 to app2, but individual closed apps compared to something federated (something open). There can also be closed individual apps with strong free speech policies and not banning people (it’s very easy to say in hindsight, but “provider of reactions” could have seen this coming). You can guarantee a ban-free environment by decentralizing totally and removing the ban ability from anyone. I don’t think preventing censorship was the initial goal of @aschrijver , though.

1 Like
11

(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.

4 Likes
12

Delegating community management

Because this is a wild brainstorm, and I just saw this topic Calling out for volunteer Community Managers :mega:   … I thought:

→ What if community management was federated?

You are fresh community manager on a newly installed Discourse forum, a complete noob on the admin interface and community-building practices. What if you could call in the help of an experienced community manager for certain period of time to advise you and look over your shoulder?

Now I know y’all are going to say: “Why not just create a staff account on that forum… no federation needed!” and you’d be right. But let’s turn it around and maybe make this more interesting: What if I wanted to offer my Discourse and community management skills either as volunteer or professional (i.e. paid)?

I’d want to be able to productively handle as many communities as possible in my ‘customer portfolio’. This leads to a triple win:

  • New community managers can obtain onboarding service to get them started more quickly.
  • Community managers can benefit more broadly from their skills, beyond their own community.
  • The two previous bullets mean Discourse has added another USP to their product.

How would this look like then? I don’t know… many possibilities. Some suggestions, where in each of them the delegated admin works from their own forum portal via federation, managing potentially many communities:

  • Delegated admin can set forum Settings, install plugins/components/css, which the real admin approves before they take effect.
  • Delegated admin has access to Staff-only categories and groups and participates in discussions to give their advice.
  • Delegated admin handles flags raised in the forum, where only the topic with the flag is federated to their portal.
  • Delegated admin, knowing the community landscape, helps arrange partnerships with other communities, and sharing of content.

Consider from above the following:

This may also be a value-added service and can be combined with the above. All parties involved have an interest in delegated admins being vetted as good community managers to a certain extent. Discourse (the company) may only allow people to become delegated admins if they are on a (paid?) subscription. Discourse or a partner may offer a community management course that, when passed, rewards a certificate with stamp of approval by @codinghorror.

Well… if you like the idea or not. It was a nice brainstorm session for me, ha ha :grinning_face_with_smiling_eyes:
Maybe you can make it better?

Edit:

Discourse itself would use this service too. At the start of our paid subscription one member of the Discourse team was part of our forum’s staff to offer the same kind of help. With this they can do that from their own remote ‘cockpit’, or… delegate it.

Another thing that deals with sharing parts of a community… A number of times when I posted a topic on Meta asking for specific help, the topic was made private (sometimes because it contained sensitive information) and dealt with as a ‘Support ticket’ by the Discourse team. With federation I might have the Support part of Meta be integrated in my own forum.

4 Likes
13

(Formatting mine). I really like that definition @JE-FF, and perfectly fits the innovative approach to take with ‘community has no boundary’ / ‘discourse-as-a-fabric’ concepts. I doubt though, as I also mentioned to @Mevo, if Discourse should really want to challenge Big Tech social media. They could if they wanted to, but there’s no need. Discourse is quite successful in its own right, and they are positioned differently now, i.e. as a multi-tenant SaaS, a ‘cloud of independent community forums’. Though by stretching community concepts beyond tenant boundaries, they may be better positioned against their rivals, both in the forums and social media space.

2 Likes
14

A big thank you, @aschrijver . It’s very clear, and honestly, I almost totally agree with you on everything you said. I wrote my messages with some kind of idea in mind that what you were proposing was a “stepping stone” with “full (and totally open) federation” as the ultimate goal. Now, I’m not even sure where it comes from, and you may even never had said anything like that. It may be a misinterpretation (and invented idea) from myself, or I mixed up things said by other people.

ActivityPub for all it could ALLOW to do, while you can still choose how you want to do things, yes, all this sounds amazing to me. I guess you are right there may be confusion between ActivityPub and Fediverse (you already explained it in the other topic on ActivityPub).

Personally, I do love all the ideas you brought. On the federated “community management”, it could also be very useful to have access to moderators that way. Moderators you could use temporarily when your community is heating up, or when there is for example a special event requiring more moderators (all this was maybe included in “community management” in your mind. You did talk about flags. But you could equally have access to more “admin” type of people, as to “moderators”, or “community managers” if you define these tasks as being different).

As it has been said earlier, all this can be achieved “on the side” through plugins and/or a side site (there could be a “freelance” side site listing and proposing services with people going to work in the community directly. It’s not as nice as having their own platform from where they can manage everything remotely and aggregated thanks to ActivityPub, but it would already be a good start).

It all depends if the Discourse team would want to use some of these ideas to implement them directly in Discourse or not.

4 Likes
15

I disagree here. I have been using multi site setups to facilitate group ownership of a Discourse instance where a close group could become its own Staff while keeping a direct link to the larger community. IMO playing with community boundaries empowers the community by using the principle of subsidiarity: that decisions are made as close as possible to practice.

16

First, you seem to interpret what he said as "users are going to misbehave without some ‘staff control’ ", which isn’t what he said, IMO. Secondly, he only talked of a “wholly different community dynamic”, without any judgment of this being good or bad. You actually seem to agree with him by saying it’s a good thing (it’s still “different”)

But this wasn’t the discussion. It’s wasn’t about this “control”, nor having any problem with users.

17

Yes, mostly it was about showing how broad a range of options there are, and full flexibility to tune to particular scenario’s. If I keep my eye purely on the ActivityPub ball, it allows the implementer of federation features full ‘ball control’. The use cases that are implemented are all equally valid ones (assuming they were designed deliberately as part of product development).

I see that @hellekin’s case is indeed not in the full freedom end of the spectrum, and it would be interesting to elaborate further. @hellekin is juggling more forums than me, and in creative ways, as can be seen on the SocialHub forum, where individual ActivityPub software teams have control over their own sections of the forum. These teams often have another independent forum of their own (e.g. in the case of Mastodon). They must be encouraged to do the ‘double work’ to keep the AP community in the loop of custom federation extensions they build into their own softwares. Besides that SocialHub has, what can be considered as, satelite forums.

3 Likes
18

I just decided to sign up to yet one more Discourse forum, just to help them and provide (copy/paste) some useful pointers to topics on other forums. Yet one more Discourse user account to manage.

The forum is Fedeproxy, for a new ActivityPub project that aims to synchronise code forges (Github, Gitlab, Gitea, etc. repositories) with one another. It might become an implementation of the Forgefed protocol, and is interesting to mention here for 2 reasons:

  1. This is yet another example of a completely different business domain that can benefit greatly from ActivityPub federation.
  2. If Discourse had federation support this forum’s #development category could be 2-way synched with SocialHub #software subcategory, without need to work on 2 forums and duplicate discussions.

Update:

On Fedeproxy forum one user (who btw didn’t want to sign up here, just for the sake of leaving just one post) pointed me to an interesting Linked Data ontology for communities, the SIOC Core Ontology Specification, where SIOC project stands for “Semantically-Interlinked Online Communities”. The ontology defines the following semantics in Linked Data:


semantically-interlinked-online-community-ontology

Mentioning here, because it highlights thinking in business domain / vocabularies and can be an inspiration to the brainstorm :slight_smile:

(PS. Don’t let yourself be led astray by the term “Semantic Web” in the SIOC specs. That’s not what this is about - way too complex - but rather seeking closed Linked Data vocabularies to define a particular domain.)

Update 2:

I found a great project today, also in a similar domain as Discourse, and started a “Community has no boundary” discussion there:

https://github.com/pubpub/pubpub/discussions/1249

PubPub is part of Knowledge Futures Group, who are also working on the Open Distributed Knowledge Graph project Underlay (which comes close to an idea I have for knowledge aggregation from Discourse forums).

Update 3:

I realized that the discussion about Community is much broader than Discourse alone, as community concepts are so universal throughout our society. For the Fediverse I started a discussion about standardization of a Community domain and modeling an ActivityPub extension after it:

8 Likes
19

Activitypub is a good idea, but even brand new software implementing it as first class citizens have to fix quite a few holes in the specs – so for us it makes sense to wait and see.

Also, this is totally doable as a plugin if it is something a particular group is super passionate about.

13 Likes
20

It would be awesome to see such an integration pull requested into the #chat-integration app so we can simply x-post by tag / category / mention after adding our credentials. Cheers!

7 Likes
21

Thank you @codinghorror. Yes, indeed in the ActivityPub spec there are holes. But they are more-or-less deliberately present, both because the spec authors didn’t want to create an all-inclusive huge and complex technology standard, plus - at the time of witing - they didn’t know how the spec would evolve. So they waited for reference implementations (this also had some drawback, like e.g. Mastodon using a custom client API instead of the Client-to-Server part of the spec, but Mastodon also defined some real handy namespace extensions to be used).

Currently most of these holes have been filled in by other open standards (though there are still some to be plugged). There’s HTTP Signatures for Server-to-Server federation (or - less used - JSON-LD signatures), for federated user mentions Webfinger is used. Client-to-Server uses OAuth2 Client Credentials and there are de-facto specs NodeInfo / NodeInfo2 to communicate server capabilities.

I agree that a great number of things discussed in this thread (the majority probably) can be implemented using Plugins and the great Discourse API’s. It would as @sunjam says indeed be awesome if someone would venture there :slight_smile:

Derived from this brainstorm I have initiated some more general discussions on the SocialHub forum, that I’d like to refer to:

Update 2021/03/07: On SocialHub in the topic on creating a Community vocabulary AP extension, I elaborated a bit more on how Discourse would fit into a community model. See my post:

7 Likes