Yes but that would be a extensive and expensive plugin.
1 Like
With SSO or LDAP can I allow login back and forth without having to move everyone to one domain login only?.
For example I have forum A, B, C. Iâd like members of forum A to be able to login and post with its forum A credentials to forum B and C. Same to happen to registered members of B and C.
I think this post and the following ones should go to their own topic since they concern a subset of the features discussed here.
1 Like
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) may be of help to you 
1 Like
In theory, I suppose that another possibility besides making a Discourse plugin that functions as an ActivityPub Federation Protocol server would be to set up accounts on a separate ActivityPub server that honors the client Social API protocol, and have a Discourse plugin speak the client protocol to that server, rather than be an ActivityPub server. This could have a benefit to closer integration into existing ActivityPub nodes. But I donât think itâs easier to implement than the server protocol, and it would be a lot more manual setup work for the forum operator than being a federation protocol server.
In my idea for what to implement, to allow the possibility of user interaction, there would have to be a way to distinguish discourse-user-actors from discourse-system-actors (e.g. categories). I could imagine that @#slug@discourse.example.org would be a category actor, leaving room for the later addition of @username@discourse.example.org user actors. But given the prevalence of hashtags that might simply not work in practice.
It would be simpler to just focus on points 1-3 on the theory that 4-5 are getting close to trying to turn Discourse into a general purpose ActivityPub server, which definitely isnât the point.
2 Likes
Mastodon uses the following regular expressions for validation:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=^|[^\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\.\-]+[[:word:]]+)?)/i
As far as I can tell, that USERNAME_RE is applied to remote users, so itâs not clear to me how to have Discourse users and categories in separate namespaces like that. It also rules out normal subcategory slugs. @parentcategory:subcategory@discourse.example.org wonât work with that RE either.
I guess there could be an optional subdomain @username@users.discourse.example.org but that would take more SSL and DNS setup and probably be misconfigured a lot. Itâs maybe just not worth going there.
1 Like
Maybe it makes sense not to create a federation with other platforms, but to create a federation between all instances of discourse, since the number of instances of discourse is very large
1 Like
There is huge potential here, for sure. The possibilities and feasibilities warrant thorough and sober consideration.
This might be Xanadu territory⌠(Read Jeffâs post above and follow the link in it.) â Such broad integration is also probably undesirable to most admin/operators of Discourse instances. A formal survey of admins & operators is in order (as opposed to âsurvey by traffic levelâ in discussion forums).
This looks like an invitation to security hacks since it dangles the âkeys to the kingdomâ of anyone who can hack the user credentials of any one of the federated sites. At the very least these features would have to be turned off by default or explicitly loaded as pluginsâwith most security features enabled and locked down. Zoom taught us this lesson by rightfully leaving their platform open and easy to use (to quickly gain and cultivate users on ramp-up) but then had to quickly lock down once the ruffians found the front door unlocked.
Nevertheless, a micro-federation of sites would be a boost to Discourse implementation. If I could create a circle of sites for my municipality that unites the same pool of users (county/city citizens for example), this would put people in communication and could enable some positive outcomes in local governance and community life. This same principle also applies to any business large enough to justify the overhead of administering multiple Discourse instances so that each division can have its own Discourse container with easy navigations to other divisions. THAT would be the embodiment of meta.discourse.
Jeff, Sam, and Co. [@codinghorror @sam] and/or their Steering Committee would first need to decide, however, whether Discourse is a social platform or an enterprise platform. My vote is for enterprise because I see the most potential there for both sides of this split. Enterprise will produce the greatest financial reward and immediate social benefit by improving businessesâ ability to support employees (take good care of the business and the business can take good care of you). Some of those commercial funds could probably then support a social.discourse.org foundation. Itâs also very likely that features useful to an enterprise will carry over well to the social domain. These two factors make for an overall win-win.
The two domains need to be distinct, though, because theyâre so different. And nice-to-have features will necessarily need to favor whichever version is the primary use case.
Happily, the benefits flow both ways since anyone interested in social.discourse.org gets their reward from the social aspects of community building and being able to pursue community-related activities, so will workâand often work hardâfor these non-financial rewards. This social.discourse.org work will inevitably lead to development and features that are useful in the enterprise context and thereby return value to Enterprise Discourse Incorporated in exchange for non-profit support of the Social Discourse Foundation. Even more win-win.
Notice that there isnât a single exclamation point above. These are just plain facts and statements of likely outcomes. Very pragmatic.
Iâve been looking for a suitable GroupWare platform for my businesses for several years now. Slack briefly inspired high hopes since it was developed for internal business use (and has a very interesting origin story) but didnât even make it through first-round screening. Iâm very impressed with Discourse and optimistic about it.
1 Like
Thatâs the whole point of this topic, i.e. between Discourse instances.
It is stated in the OP:
2 Likes
Right, and
and
a micro-federation of sites would be a boost
All on-topic, no? 
Not necessarily a prerequisite. There is the plugin ecosystem to be considered.
Significantly large features are often developed as plugins or even Theme Components (where possible) that do not involve such an administrative overhead nor centralised planning.
Thatâs part of the beauty of the Discourse ecosystem.
Pavilion, for example, created Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard (to name but a few) all without consultation with CDCK. Hence, in part, our involvement in this discussion.
7 Likes
God bless our plug-in developers! They generously provide proof-of-concept examples that can be field-tested and considered for inclusion in the core product. Your multilingual plug-in is an excellent example!
Over at python.org, this role is played by library developers who sometimes create âgotta have thatâ functions that are accepted for inclusion in the Python core package or standard distribution library.
2 Likes
I have been advocating Discourse to add federation support in a bunch of topics on this forum, like here. With the Fediverse going mainstream now, and Tumblr and maybe Flickr and such adding federation support, the question is if Discourse has more interest for adding support as well.
I was contacted by the core developer of Flarum for advice on AP implementation and passed some links back, among which the one just mentioned.
PS. At SocialHub discourse forum, developer community for the Fediverse, we are looking for a long time how we can be part of Fediverse as separate forums have shown to be too much of a barrier for most people to participate.
7 Likes
Iâve gotten mildly interested in Mastodon lately (enough to purchase a domain name, but not actually install Mastodon), so Iâve read a bit about authenticating Discourse with Mastodon.
I found a few posts suggesting that itâs harder than people thought. IIRC, it looked like a grant had been offered to develop a plugin but it seemed to have fallen though. My wild guess is that itâs a $10,000 problem; if Iâm right, thatâs the kind of advocacy youâre going to need.
Edit: but I was conflating authentication with federation.
1 Like
My general concern here is that the ideas are generally enormous, it is super hard to break them down into small pieces.
I do find the idea of federating interesting. A possible concrete implementation could be:
- Allow Discourse admins to federate a category.
- Users on mastodon can then follow it, eg follow:
announcements@meta.discourse.org - When new announcement topics are created, a new post is federated with an excerpts and link to the original.
- As users respond on discourse, new replies are federated and attributed (as replies to original topic)
- When someone on the fediverse replies, a âshadowâ post is made on the topic attributed to the poster on mastodon.
Something like that is at least small enough to properly fit in my head.
13 Likes
The issue with ActivityPub is that it is an easy-to-read open standard, but implementing it doesnât make you âpart of the Fediverseâ just yet. Thereâs a bunch of other things to be implemented, and - for a Discussion Forums domain - a custom ActivityPub vocabulary for message exchanges. There are other projects to âbootstrapâ from and some libraries to possibly adopt, but thereâll indeed be some significant development that is needed.
In terms of advocacy⌠I personally feel that, when done well, AP support can add USPâs to the product. Not having to sign up to every forum is one thing⌠it is a barrier for me too. Shall I sign up to yet one more Discourse, just for this single post I wanna add?
But federation might bring much more value. In my dream scenario I would install a personal Discourse or sign up to an instance, that - like Mastodon - would be completely empty at the start. Then Iâd fill it in with community structure myself, based on my needs and interests. Choose this themed group, and add it under this category, add another group.
Update: Cross-posted with @sam ⌠this was in reaction to @pfaffman
5 Likes
Yes, thatâd be a great start. Lemmy link aggregrator works somewhat like that, where it offers a federation of Communities. Note that - though itâd be a very nice-to-have to interact more broadly - federation could be implemented just between Discourse instances / tenants at the start.
Not everything fits to Mastodon⌠its a Microblogging app, does not support markdown (though other fedi apps do that).
Currently further federated Groups support is being worked on. Lemmy is an example. Bonfire will add Google+ like circles, etc.
3 Likes
Yes! This is the workflow Iâd love to see. And promote. 
The length of the excerpt would conveniently be configurable, with 0 meaning the entire article rather than an excerpt. Note that the Mastodon 500-character limit is arbitrary, and has nothing to do with the Fediverse, ActivityPub, or ActivityStream. The Mastodon nodes I run currently have 2000-character limits, and the social.kernel.org limit is 31337 characters. Even default Mastodon with its 500-character limit for writing posts still displays longer posts just fine.
A minor difficulty I see is that the user and category namespaces are separate in Discourse but are the same âActorâ in ActivityPub, and at least Mastodon has a fairly restrictive regexp for recognizing Actors. Given @announcements@meta.discourse.org for the announcements category, this comment would be federated as authored by @mcdanlj@meta.discourse.org
By default, as a Discourse admin Iâd want to use the category slug as the Actor name. I suppose that if, when the admin sets up federation for a category, they select the Actor name, which would default to the slug, and would be (like a group name) unique with respect to Discourse User names.
(Incidentally, I used to worry about the Mastodon regex for recognizing actor names, but I think that itâs actually only used for at-mentioning people, which isnât valuable here anyway. So it might even work to have, say, #documentation:admins represented as @documentation:admins@meta.discourse.org though Iâd definitely want to test that with several of the major microblogging systems, definitely including Mastodon and Pleroma. )
3 Likes
I think what this would actually look like from the perspective of, say, a Mastodon or Pleroma user, would be that @announcements@meta.discourse.org would boost / reblog a topic post by, say, @sam@meta.discourse.org and then also boost/reblog a comment post by, say, @mcdanlj@meta.discourse.org as a comment to the OP â Neither the OP nor a comment is actually made by the category, itâs made by a person, in a category.
It might be that the plugin could initially only implement webfinger for the category Actors (in order to be able to follow them), but it might make sense in the end to implement it for individual users as well. I might reasonably, on Mastodon, want to follow @sam@meta.discourse.org to see his posts and comments.
2 Likes
Question: what is the current status of this discussion and the plans for possible implementations? Do you need any testing support for example? Or is that question âfar too earlyâ 