A common problem that many Discourse users face is the inability to show an aggregation of all the interest groups that they are subscribed to. There’s no easy way to consume content from multiple Discourse instances in the form of a central and social user feed. Centralised platforms like Reddit get around this by having a single login for all communities and an aggregate feed of all the communities shown in a single stream on the reddit.com landing page. This latter feature is what we’d like to replicate in Discourse by means of the ActivityPub protocol.
For example, Person A frequents multiple Discourse instances: one for politics, two for hobbies, one for their local neighborhood forum but has no way to consume all relevant content in one single feed. In comparison, if you have joined multiple Facebook groups or Reddit subs, the most relevant posts already show up in your feed.
Spec (v1)
We could prototype an MVP by enabling the following features through a Discourse plugin:
Generate an ActivityPub feed on demand (for every page that already has an RSS feed)
Similar to adding .rss to the url, this will allow the fetching of content using the AP protocol on requesting the right endpoint.
We may even be able to enable this for private content by appending user api keys to the url.
Let forum admins enable ActivityPub (outgoing) on a per-category basis or keep it default-on? (I believe @Falco had some thoughts here)
Figure out a way to consume this content on a Discourse forum / Mastodon feed (incoming)
Next Steps
We definitely need to start small so at first, we need to decide on a small, feasible set of features that will go into the first iteration. I’ve been going through the ActivityPub protocol but I’m not too familiar with the inner workings of it yet. Therefore, I’m inviting others who have shown a lot of interest in this to the discussion (@Falco, @hellekin, @merefield) to help us build a feasible spec for the first iteration and recommend changes for the spec above.
I would start by saying: shouldn’t we focus on the what not the how, initially? Tech arch comes later? The reason I say that is it might limit the functionality if chosen too early?
I would love to see for Version 1. a ‘Discovery of Discovery’ lists, starting with:
‘Latest’ list which showed a preview of each recent topic from the included sources (simple union of Latest from all sources)
‘Watched’ list, which showed a preview of each Topic that has activity you have selected to be notified about. (this takes its precedent from the existing mobile app - its exploding the notifications of new activity on watched Topics to the underlying Topic previews themselves).
I must say the original proposal involving Facebook analogy gets past my understanding: I have no clue what Facebook does, and I do not understand how it relates to Discourse in any way.
My understanding of ActivityPub support for Discourse would be that it can help federate topics, or even share a category among Discourse instances. For example, one announcement topic on discourse.joinmastodon.org could be federated to socialhub.activitypub.rocks in the related #software:mastodon category: there, local users could like, reply, quote, etc., as if it were a local topic, except the original topic would live on joinmastodon’s instance.
Another aspect of it is that if one has an account on both instances, there should be a way to link these accounts together, i.e., to use one specific Discourse instance as the main identity provider. I understand that this is not the focus of a first iteration, but it’s good to keep in mind, since we could end up having “sign in with [put your favorite ActivityPub implementation here]”.
What I understand from the proposals above is a replication of the Discourse app on Android, where you have a list of instances, and get notifications from all of them. It seems a bit dangerous to interleave unrelated responses from many sources, especially as they lose context.
Did I understand correctly, and would my understanding make a good second step for your vision of integrating ActivityPub with Discourse?
All the current ActivityPub implementations expect posts to be published by stable Actors, so you might need one of the following:
A system account that publishes all posts
One account per followable feed
One account per followable feed, which makes Announces of posts that are putatively authored by an account per Discourse user
The first is likely easiest to implement; the third does the best job of meshing the data models.
There’s also the choice of if we want to publish full topic content, topic first-posts only, or something like the StackExchange twitter feeds where distinct posts are made promoting posts from the /top page. Or that could just be how the “top posts” feed works, and the other feeds publish everything…
On a technical level, the URL should not need to change: all servers will send Accept: application/activity+json or its alternates.
A reader application that mixes feeds from different sources at different times in ActivityPub - recreating the “algorithmic timeline” as an opt-in thing - is something I’ve been wanting for a while, and doesn’t seem to be existent today.
@hellekin: I think that cross-domain authoring has a high chance of fatally circumventing a lot of the anti-spam protections that Discourse has. Reading is more important to implement: after all, Reading is Fundamental!
I don’t think so: remote users could still be staged, unless they link their remote account to a local one in which case antispam would apply to that account.
I only had a short look at the comments, I must confess. I would suggest that every category would be an own actor (with the type “Group”). Then people from outside can simply subscribe to specific categories. Posts in these categories can the be realized with having the “Group” account announced the user posts. So we do have both the category and the author. This is the way we are doing it with our own software. When using JSON-LD signatures, this would be safe for non public categories as well.
Question is what to do with comments from outside. I would suggest that the group accounts are defined as “manually-approve”. Then one could add some validation process to avoid random spam. These validated accounts should then be able to comment on these posts.
This would instantaneously allow people from (nearly) the whole fediverse to connect and interact with discourse systems.
Every category Group actor can have an owner who has power to manage the category: control posting permissions, ban or remove users, set visibility (public or private)…
Local users would create categories on their instance, as long as the instance staff approve their category creations.
If a category owner doesn’t fit their position, the site staff can change them.
That’s the way many centralized forums and communities work. What to improve is making it federating.
Nevertheless, there are still problems:
Should actor ids be mutable? Discourse usernames can be set to modifiable in the site settings. However, I doubt whether other AP software can handle this. Is Object's `id` immutable? - ActivityPub - SocialHub
(More to be mentioned)
못 가서 죄송합니다. 참고로, 우리는 NGI0 자금 지원을 신청하지 않았고, 현재 이 프로젝트에 작업 중인 사람은 아무도 없습니다. 프로토콜에 익숙하지 않아서 이 일을 주도하기에는 가장 적합한 사람이 아니지만, @Falco 님께 언급해서 혹시 이 일을 진행할 생각이 있거나 관심이 있는지 확인해 보겠습니다.
글쎄요, 당시에는 팀원 중 한 명이 신청했었습니다. 그 사람이 더 이상 팀에 있지 않고, 여러분이 선정되었기 때문에 누군가는 이를 승인해야 했을 텐데, 어떤 "우리"를 말씀하시는 건지 모르겠습니다. 어쨌든 @Falco와 논의하는 것을 기대하고 있습니다. 어떤 형태의 AP(ActivitPub) 지원도 ActivityPub 커뮤니티에 정말 도움이 될 것입니다. 특히 Discourse 인스턴스 간 작업을 용이하게 하고 Fediverse와의 통합을 개선할 수 있기 때문입니다.
스팸 방지 문제에 대해서는 충분히 인지하고 있지만, 로컬 계정을 실제로 등록하기 전까지 등록되지 않은 이메일 사용자와 같은 스테이징 Fediverse 사용자를 통해 이 문제를 완화할 수 있다고 생각합니다.
네, 과거에 우리는 자금 지원을 신청했습니다. 하지만 올해早些에 NLnet 팀과 연락하여 프로젝트를 종료하고 우리에게 예약되어 있던 자금을 해제하기로 했습니다. 당시 선정되었더라도, NGI0와의 협력은 현재로서는 취소되었습니다. 물론, 미래에 제안서를 제출할 자유는 있습니다.
@riking도 관심이 있을 것 같다는 것을 방금 기억났습니다
1개의 좋아요
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
흥미롭네요.
이 프로젝트는 유럽연합 집행위원회의 차세대 인터넷(Next Generation Internet) 프로그램의 재정적 지원으로 NLnet이 설립한 NGI0 Discovery Fund를 통해 자금을 지원받았습니다. 이 기금은 통신 네트워크, 콘텐츠 및 기술 총국(DG Communications Networks, Content and Technology)의 관할 하에 보조금 계약 번호 825322에 따라 운영됩니다.
그러니까: 여기서 말하는 "Discourse"가 또 다른 "Discourse"를 의미하는 건가요?
"프로젝트 자체 웹사이트: https://discourse.org"라는 부분 때문에 궁금해서 물어봅니다…
어쨌든