Sí, pero eso sería un plugin extenso y costoso.
1 me gusta
Con SSO o LDAP, ¿puedo permitir el inicio de sesión de un lado a otro sin tener que trasladar a todos a un solo inicio de sesión de dominio?
Por ejemplo, tengo los foros A, B y C. Me gustaría que los miembros del foro A pudieran iniciar sesión y publicar con sus credenciales del foro A en los foros B y C. Lo mismo debería ocurrir con los miembros registrados de B y C.
Creo que esta publicación y las siguientes deberían ir a su propio tema, ya que se refieren a un subconjunto de las características que se discuten aquí.
1 me gusta
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta puede ser de ayuda 
1 me gusta
En teoría, supongo que otra posibilidad además de crear un plugin de Discourse que funcione como un servidor del Protocolo de Federación ActivityPub sería configurar cuentas en un servidor ActivityPub separado que respete el protocolo client Social API, y tener un plugin de Discourse que hable el protocolo cliente a ese servidor, en lugar de ser un servidor ActivityPub. Esto podría tener el beneficio de una integración más estrecha con los nodos ActivityPub existentes. Pero no creo que sea más fácil de implementar que el protocolo del servidor, y sería mucho más trabajo de configuración manual para el operador del foro que ser un servidor del protocolo de federación.
En mi idea de lo que implementar, para permitir la posibilidad de interacción del usuario, tendría que haber una manera de distinguir los actores-usuario-de-Discourse de los actores-sistema-de-Discourse (por ejemplo, categorías). Podría imaginar que @#slug@discourse.example.org sería un actor de categoría, dejando espacio para la adición posterior de actores-usuario @username@discourse.example.org. Pero dada la prevalencia de hashtags, eso podría simplemente no funcionar en la práctica.
Sería más simple centrarse solo en los puntos 1-3 bajo la teoría de que 4-5 se acercan a intentar convertir Discourse en un servidor ActivityPub de propósito general, lo cual definitivamente no es el objetivo.
2 Me gusta
Mastodon utiliza las siguientes expresiones regulares para la validación:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?\u003c=^|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
Por lo que puedo decir, USERNAME_RE se aplica a usuarios remotos, por lo que no está claro cómo tener usuarios y categorías de Discourse en espacios de nombres separados de esa manera. También descarta las subcategorías normales. @parentcategory:subcategory@discourse.example.org tampoco funcionará con esa RE.
Supongo que podría haber un subdominio opcional @username@users.discourse.example.org, pero eso requeriría más configuración de SSL y DNS y probablemente se configuraría mal con frecuencia. Quizás no valga la pena.
1 me gusta
Quizás tenga sentido no crear una federación con otras plataformas, sino crear una federación entre todas las instancias de discourse, ya que el número de instancias de discourse es muy grande.
2 Me gusta
Claro que hay un gran potencial aquí. Las posibilidades y viabilidades justifican una consideración exhaustiva y sobria.
Esto podría ser territorio de Xanadu… (Lea la publicación de Jeff arriba y siga el enlace que contiene). Dicha integración amplia probablemente tampoco sea deseable para la mayoría de los administradores/operadores de instancias de Discourse. Está en orden una encuesta formal de administradores y operadores (en contraposición a una “encuesta por nivel de tráfico” en foros de discusión).
Esto parece una invitación a hackeos de seguridad, ya que ofrece las “llaves del reino” a cualquiera que pueda hackear las credenciales de usuario de cualquiera de los sitios federados. Como mínimo, estas funciones tendrían que estar desactivadas por defecto o cargarse explícitamente como plugins, con la mayoría de las funciones de seguridad habilitadas y bloqueadas. Zoom nos enseñó esta lección al dejar correctamente su plataforma abierta y fácil de usar (para ganar y cultivar usuarios rápidamente durante el aumento), pero luego tuvo que bloquearla rápidamente una vez que los rufianes encontraron la puerta principal sin llave.
Sin embargo, una microfederación de sitios sería un impulso para la implementación de Discourse. Si pudiera crear un círculo de sitios para mi municipio que uniera al mismo grupo de usuarios (ciudadanos del condado/ciudad, por ejemplo), esto pondría a las personas en comunicación y podría permitir algunos resultados positivos en la gobernanza local y la vida comunitaria. Este mismo principio también se aplica a cualquier empresa lo suficientemente grande como para justificar el costo de administrar múltiples instancias de Discourse, de modo que cada división pueda tener su propio contenedor de Discourse con una navegación fácil a otras divisiones. *ESA sería la encarnación de meta.discourse. *
Jeff, Sam y Cía. [@codinghorror @sam] y/o su Comité Directivo tendrían que decidir primero, sin embargo, si Discourse es una plataforma social o una plataforma empresarial. Mi voto es por empresarial porque veo el mayor potencial allí para ambos lados de esta división. La empresa producirá la mayor recompensa financiera y el beneficio social inmediato al mejorar la capacidad de las empresas para apoyar a los empleados (cuidar bien del negocio y el negocio podrá cuidar bien de usted). Algunos de esos fondos comerciales probablemente podrían respaldar una fundación social.discourse.org. También es muy probable que las funciones útiles para una empresa se trasladen bien al dominio social. Estos dos factores crean una situación en la que todos ganan.
Los dos dominios deben ser distintos, sin embargo, porque son muy diferentes. Y las características deseables necesariamente tendrán que favorecer la versión que sea el caso de uso principal.
Afortunadamente, los beneficios fluyen en ambos sentidos, ya que cualquiera interesado en social.discourse.org obtiene su recompensa de los aspectos sociales de la construcción de comunidades y de poder perseguir actividades relacionadas con la comunidad, por lo que trabajará, y a menudo trabajará duro, por estas recompensas no financieras. Este trabajo de social.discourse.org inevitablemente conducirá al desarrollo y a características que son útiles en el contexto empresarial y, por lo tanto, devolverán valor a Enterprise Discourse Incorporated a cambio de apoyo sin fines de lucro a la Fundación Social Discourse. Aún más, todos ganan.
Observe que no hay un solo signo de exclamación arriba. Estos son solo hechos simples y declaraciones de resultados probables. Muy pragmático.
He estado buscando una plataforma GroupWare adecuada para mis negocios durante varios años. Slack inspiró brevemente grandes esperanzas, ya que se desarrolló para uso interno de negocios (y tiene una historia de origen muy interesante), pero ni siquiera pasó la primera ronda de selección. Estoy muy impresionado con Discourse y soy optimista al respecto.
1 me gusta
Ese es el propósito de este tema, es decir, entre instancias de Discourse.
Se indica en el OP:
2 Me gusta
De acuerdo, y
y
*una microfederación de sitios sería un impulso
Todo está en tema, ¿no? 
No es necesariamente un requisito previo. Hay que tener en cuenta el ecosistema de plugins.
Las características significativamente grandes a menudo se desarrollan como plugins o incluso como Componentes Temáticos (cuando es posible) que no implican tal sobrecarga administrativa ni planificación centralizada.
Esa es parte de la belleza del ecosistema de Discourse.
Pavilion, por ejemplo, creó Ubicaciones, Vistas de Lista de Temas, Multilingüe, Seguir, Diseños, Asistente Personalizado (por nombrar solo algunos) todo sin consulta con CDCK. Por lo tanto, en parte, nuestra participación en esta discusión.
7 Me gusta
¡Dios bendiga a nuestros desarrolladores de plugins! Proporcionan generosamente ejemplos de prueba de concepto que pueden ser probados en campo y considerados para su inclusión en el producto principal. ¡Tu plugin multilingüe es un excelente ejemplo!
En python.org, este rol lo desempeñan los desarrolladores de bibliotecas que a veces crean funciones “imprescindibles” que se aceptan para su inclusión en el paquete principal de Python o en la biblioteca de distribución estándar.
2 Me gusta
He estado abogando por que Discourse agregue soporte de federación en varios temas de este foro, como aquí. Ahora que el Fediverso se está volviendo popular, y Tumblr y quizás Flickr y otros están agregando soporte de federación, la pregunta es si Discourse tiene más interés en agregar soporte también.
Me contactó el desarrollador principal de Flarum para pedirme consejo sobre la implementación de AP y le pasé algunos enlaces, entre ellos el que acabo de mencionar.
PD. En el foro de Discourse de SocialHub, una comunidad de desarrolladores para el Fediverso, hemos estado buscando durante mucho tiempo cómo podemos ser parte del Fediverso, ya que los foros separados han demostrado ser una barrera demasiado grande para que la mayoría de las personas participen.
7 Me gusta
Últimamente me he interesado un poco en Mastodon (lo suficiente como para comprar un nombre de dominio, pero no para instalar Mastodon), así que he leído un poco sobre la autenticación de Discourse con Mastodon.
Encontré algunas publicaciones que sugerían que era más difícil de lo que la gente pensaba. Si mal no recuerdo, parecía que se había ofrecido una subvención para desarrollar un plugin, pero pareció que fracasó. Mi suposición es que es un problema de $10,000; si tengo razón, ese es el tipo de apoyo que necesitarás.
Edición: pero estaba confundiendo la autenticación con la federación.
1 me gusta
Mi preocupación general aquí es que las ideas son generalmente enormes, es súper difícil desglosarlas en piezas pequeñas.
Encuentro interesante la idea de la federación. Una posible implementación concreta podría ser:
- Permitir a los administradores de Discourse federar una categoría.
- Los usuarios de Mastodon podrán seguirla, por ejemplo, seguir:
announcements@meta.discourse.org - Cuando se creen nuevos temas de anuncios, se federará una nueva publicación con un extracto y un enlace al original.
- A medida que los usuarios responden en Discourse, las nuevas respuestas se federan y se atribuyen (como respuestas al tema original).
- Cuando alguien en el fediverso responde, se crea una publicación “sombra” en el tema atribuida al publicador en Mastodon.
Algo así es al menos lo suficientemente pequeño como para caber bien en mi cabeza.
13 Me gusta
El problema con ActivityPub es que es un estándar abierto fácil de leer, pero implementarlo no te hace “parte del Fediverso” todavía. Hay un montón de otras cosas que implementar y, para un dominio de Foros de Discusión, un vocabulario ActivityPub personalizado para los intercambios de mensajes. Hay otros proyectos de los que “arrancar” y algunas bibliotecas que posiblemente adoptar, pero ciertamente se necesitará un desarrollo significativo.
En términos de promoción… Personalmente, siento que, cuando se hace bien, el soporte de AP puede añadir puntos de venta únicos (USP) al producto. No tener que registrarse en cada foro es una cosa… es una barrera para mí también. ¿Debo registrarme en un Discourse más, solo para esta única publicación que quiero añadir?
Pero la federación podría aportar mucho más valor. En mi escenario soñado, instalaría un Discourse personal o me registraría en una instancia que, como Mastodon, estaría completamente vacía al principio. Luego la llenaría con la estructura de la comunidad yo mismo, basándome en mis necesidades e intereses. Elegir este grupo temático y añadirlo bajo esta categoría, añadir otro grupo.
Actualización: Publicado simultáneamente con @sam .. esto fue en reacción a @pfaffman
5 Me gusta
Sí, eso sería un gran comienzo. El agregador de enlaces de Lemmy funciona de manera similar, donde ofrece una federación de Comunidades. Tenga en cuenta que, aunque sería muy útil interactuar de manera más amplia, la federación podría implementarse solo entre instancias / inquilinos de Discourse al principio.
No todo encaja en Mastodon… es una aplicación de microblogging, no admite markdown (aunque otras aplicaciones de fedi lo hacen).
Actualmente se está trabajando en un mayor soporte federado para Grupos. Lemmy es un ejemplo. Bonfire agregará círculos tipo Google+, etc.
3 Me gusta
¡Sí! Este es el flujo de trabajo que me encantaría ver. Y promocionar. 
La longitud del extracto sería convenientemente configurable, con 0 significando el artículo completo en lugar de un extracto. Tenga en cuenta que el límite de 500 caracteres de Mastodon es arbitrario y no tiene nada que ver con Fediverse, ActivityPub o ActivityStream. Los nodos de Mastodon que ejecuto actualmente tienen límites de 2000 caracteres, y el límite de social.kernel.org es de 31337 caracteres. Incluso el Mastodon predeterminado con su límite de 500 caracteres para escribir publicaciones todavía muestra publicaciones más largas sin problemas.
Una dificultad menor que veo es que los espacios de nombres de usuario y categoría están separados en Discourse, pero son el mismo “Actor” en ActivityPub, y al menos Mastodon tiene una expresión regular bastante restrictiva para reconocer Actores. Dado @announcements@meta.discourse.org para la categoría Announcements, este comentario se federaría como escrito por @mcdanlj@meta.discourse.org
Por defecto, como administrador de Discourse, querría usar la “slug” de la categoría como nombre del Actor. Supongo que si, cuando el administrador configura la federación para una categoría, selecciona el nombre del Actor, que por defecto sería la “slug”, y sería (como el nombre de un grupo) único con respecto a los nombres de usuario de Discourse.
(Por cierto, solía preocuparme por la expresión regular de Mastodon para reconocer nombres de actores, pero creo que en realidad solo se usa para mencionar personas, lo cual no es valioso aquí de todos modos. Por lo que podría funcionar incluso tener, por ejemplo, #documentation:admins representado como @documentation:admins@meta.discourse.org aunque definitivamente querría probar eso con varios de los principales sistemas de microblogging, incluyendo definitivamente Mastodon y Pleroma.)
3 Me gusta
Creo que lo que esto realmente parecería desde la perspectiva de, digamos, un usuario de Mastodon o Pleroma, sería que @announcements@meta.discourse.org impulsaría / republicaría una publicación de tema de, digamos, @sam@meta.discourse.org y luego también impulsaría/republicaría una publicación de comentario de, digamos, @mcdanlj@meta.discourse.org como un comentario al OP — Ni el OP ni un comentario son hechos realmente por la categoría, son hechos por una persona, en una categoría.
Podría ser que el plugin inicialmente solo implementara webfinger para los Actores de categoría (para poder seguirlos), pero podría tener sentido al final implementarlo también para usuarios individuales. Podría razonablemente, en Mastodon, querer seguir a @sam@meta.discourse.org para ver sus publicaciones y comentarios.
2 Me gusta
Pregunta: ¿cuál es el estado actual de esta discusión y los planes para posibles implementaciones? ¿Necesitan algún tipo de soporte de prueba? ¿O esa pregunta es “demasiado pronto” 