[hm] {difu:} proyecto red social bcnencomu

[psy]

Blablabla... Pragmatismo / "pragmato-cracia" / AI <-> Democracy /
"demos-crazy".

-----------

Quizás sea interesante que la siguiente propuesta de bcnencomu (o de
quien sea) detalle algunos parámetros más concretos, para que la gente
se sitúe mejor.

Por ejemplo, una línea de tiempo (o roadmap), si se tiene una decisión
tomada sobre una aplicación a utilizar o incluso un lenguaje o un texto
con una vertiente más de investigación, si se buscan ideas y gente que
las haga funcionar.

Un nivel de prioridad (normal<crítica), sin dar demasiados detalles a
otros competid..(partidos), pero si dejando ver su relevancia y necesidad.

Recursos que puedan ser útiles y no haga falta buscar (soporte humano),
etc.

También, no es lo mismo implementar algo experimental, con el riesgo que
conlleva, que buscar una solución ya experimentada que cumpla una
función delimitada, en producción.

Es ¿D, I+D o I+D+i?. Parecen etiquetas chorras, pero si va de
"conquistar el planeta", también es bueno saberlo. ;-)

Tampoco estaría mal saber el nivel de compromiso, en por ejemplo,
mantener la infraestructura, si existirá un proceso de delegación,
cursos de enseñanza o relevo de mantenedores, etc.

Ojo, lo comento sin haber hecho antes ninguna propuesta contextual
similar. Quizás la misma, al ser de la Administración, lleve un
protocolo que pase por éste tipo de comunicados y más adelante se
detalla cada punto de otras maneras (reuniones, etc..), ni idea esa parte.

Lo que si te puedo decir es que he visto que se habla de Discourse.
Bueno, es una solución centralizada que utilizamos en otros ámbitos.
Quizás haya que resaltar las deficiencias en la gestión, de por ejemplo,
los grupos. O algunos detalles sin implementar de la federación.

Tal vez, si se trata únicamente de comunicarse mediante hilos y crear
"grupos" o "temas", con algo como BitMessage (
https://es.wikipedia.org/wiki/Bitmessage ), es más que suficiente:

""""""""""""""""""""""
A partir de la versión 0.3.5, Bitmessage introdujo una característica
llamada chan, una lista de correo descentralizada anónima. A diferencia
de las Listas de correo electrónico tradicionales:

    - un chan no puede cerrarse tirando abajo todos los servidores o un
grupo de servidores debido a la naturaleza descentralizada de los chans.
    - un chan no puede ser censurado ya que cualquier usuario de
Bitmessage que sabe la contraseña puede leer el chan o publicar
cualquier mensaje en el chan.
    - en un chan, los mensajes de los usuarios son anónimos hasta tal
punto de que los mensajes no contienen ni la dirección del emisor ni el
receptor del Bitmessage.

Existen una serie de chans públicamente conocidos dedicados a temas que
van desde la privacidad_en_Internet a la política o a los juegos de ajedrez.
""""""""""""""""""""""""

Esa parte es la más extrema en anonimato. Pero se pueden generar
etiquetas para las direcciones que permiten identificar a la personas, a
los grupos y a los temas.

Lo digo además, porque sean las ciudadanas las que "mantienen" el
contenido de la red, a través de la arquitectura p2p y la Administración
únicamente trabaje como facilitadora/herramienta/pegamento. Más justo
para la ciudadania, altamente improbable. Porque no se trata únicamente
de la licencia, sino de la forma en que se despliega/mantiene el
recurso. Poco hay más "democrático" que el p2p, a la hora de comunicar
datos.

Otro detalle también interesante sobre Discourse es que no tiene un
sistema de permisos sobre el contenido, como por ejemplo tiene Elgg, lo
cual, en según que contextos, delimita más de un modo u otro su uso.

Como foro, con hilos, moderación, "me interesa", etc.. está genial.
Tiene buena estética y se ha trabajado bastante lo asíncrono.

El editor de textos para publicar es algo límitado. Las públicaciones
tienes una estética forma algo monolítica. Pero al estar modularizado,
seguro ya hay "plugins" por ahí o se puedan implementar soluciones de
manera no muy complicada, a la carta.

Sobre su seguridad, ahora mismo no sabría decir, pero supongo todo sea
cuestión de sincronizarse con la comunidad.

Hace tiempo alguna vulnerabilidad ya hemos reportado, como por ejemplo,
que utilice un parámetro redirect en el login, mediante POST. Al estar
sin filtrar (en la mayoría de los casos), permite crear ataques de
impersonación más sofisticados a través de links maliciosos...

REQUEST:

POST /login HTTP/1.0
Accept: /Content-Type: application/x-www-form-urlencoded
User-Agent: [snipped]
Host: forum.[discourse.org]
Content-Length: 60
Cookie: [snipped]
Connection: Close
Pragma: no-cache

username=foo&password=bar&redirect=http://www.whitehouse.gov/

RESPONSE:

HTTP/1.1 302 Moved Temporarily
Sever: [snipped]
Date: [snipped]
Content-Type: text/html; charset=utf-8
Connection: close
[snipped]
Location: http://www.whitehouse.gov/

[snipped]

Si el servidor (o la petición del atacante), conlleva seguir el
"Location", es posible llevarse a la gente a otros lugares sin que se
enteren tras loguearse y encadenar otro tipo de ataques (CSRF, etc..)

Pero vamos, en línea con las plataformas similares...

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/hackmeeting/attachments/20160813/214efe9e/attachment.pgp>