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)
@heluecht y @misaka4e21 mencionaron el soporte para el actor Group. Hay una discusión en curso en SocialHub sobre formas de implementarlo de manera más o menos estandarizada.
5 Me gusta
sl007
(Sebastian Lasse | @sl007@mastodon.social)
14
¡Felicidades por el dinero de la UE!
¿Hay una hoja de ruta?
¿Alguien del equipo de Discourse irá a la Conferencia de ActivityPub?
Sería un gran momento para conocer y conectar con otros implementadores de AP. https://conf.activitypub.rocks
Esperamos que podamos discutir la implementación de ActivityPub en Discourse durante el Birds of a Feather el próximo domingo en el APConf2020. Consulta el tema dedicado en SocialHub:
@rishabh, sería genial tenerte por aquí, al menos en el tema si no puedes asistir el domingo. Aún no conocemos la hora exacta, pero será por la mañana del domingo. Actualizaré esta publicación cuando lo sepa.
Lo siento, no pude asistir. Te informo de que no solicitamos la financiación de NGI0 y, por ahora, nadie está trabajando en esto. Tampoco soy la persona más indicada para impulsar esto, ya que no estoy familiarizado con el protocolo, pero haré un ping a @Falco para ver si tiene alguna opinión o interés en llevarlo adelante.
Bueno, en ese momento, uno de los miembros de tu equipo sí lo hizo, aunque ya no forme parte del equipo, y ustedes fueron seleccionados. Así que alguien tuvo que aprobarlo, por lo que no sé a qué “nosotros” te refieres. De todos modos, espero con interés discutirlo con @Falco. Algún tipo de soporte para AP sería realmente útil para la comunidad de ActivityPub, especialmente porque facilitaría el trabajo entre instancias de Discourse y mejoraría la integración con el Fediverso.
Soy consciente del problema del spam, pero creo que se puede mitigar con usuarios del Fediverso en entorno de pruebas, como los usuarios de correo electrónico no registrados, hasta que registren realmente una cuenta local.
Sí, solicitamos la financiación en el pasado, pero hablamos con el equipo de NLnet a principios de este año para cerrar el proyecto y liberar la financiación que se había reservado para nosotros. Aunque fuimos seleccionados en ese momento, la colaboración con NGI0 está cancelada por ahora. Por supuesto, somos libres de presentar propuestas en el futuro.
Acabo de recordar que a @riking también podría interesarle
1 me gusta
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
Interesante.
Este proyecto fue financiado a través del Fondo NGI0 Discovery, un fondo establecido por NLnet con apoyo financiero del programa Next Generation Internet de la Comisión Europea, bajo el amparo de la DG Redes de Comunicaciones, Contenido y Tecnología, según el acuerdo de subvención n.º 825322.
Entonces: ¿están hablando de otro “Discourse”?
Solo pregunto debido a “Sitio web propio del proyecto: https://discourse.org”…
¡Oh, no sabía que esa página existía! Escribiré un correo electrónico a nuestro contacto en NLnet para recordárselo, por si acaso olvidaron eliminarla, y publicaré una actualización aquí.
De todos modos, espero con interés discutirlo con