Social dream network book.

Deep.

 

 

[English]————————

Greetings,

This is to write down Lorea’s inhabitant’s backup plugin specifications.

 

By initializing:

1) The plugin should manage private and public documents acording to user privileges. Maybe, user’s profile can be used to get an index with current elements. Meaning: user authored documents and related by privileges other’s documents.

2) The plugin shoud offer some U.I. to check or uncheck desidered backup elements.

3) All elements of the network should be available for backup.

4) Particular points to be studied: (order from less to maximum complexity):

— a) Telegrams

— b) Links

— c) Photos

— d) Vídeos

— e) Tasks

— f) Pages

— g) Calendar

— h) Blogs

— i) Wikis

— j) Groups

— —  j.0) Elements above.

— —  j.1) Discussions, assamblies module.

— —  j.2) Mail lists

See suggested approaching methods below…

[Spanish]———————-

Saludos,

Quisiera proponer un hackaton para el tema del plugin para copias de respaldo de los habitantes de Lorea.

Sé que no hay nadie ahí escuchando, pero supongo que los pasos correctos pasan por abrir este hilo.

Igualmente, también, supongo, que en cuanto plantee la curva de aprendizaje de Lorea me vendré abajo porque veré que la imbrincación con los fósiles y cadáveres que se han amontonado pesa sobremanera. Igualmente, ahora hay energías.

Una primera aproximación:

Tomo como punto de partida el planteamiento que Blinge anotó:

Supongo que un backup de usuarias tendría que distinguir entre los documentos publicos y los escritos en privado.. una forma de seleccionar la información no necesaria y descartarla del backup… ¿Se hace backup de los post de las listas de discusión o de las páginas publicadas en un grupo y no de de los telegramas? ¿Se realiza una busqueda en la base de datos de todo lo relacionado con tal o cual usuario, se copia y comprime todo en un archivo y se envía por email?

Al estar cada usuaria metida en varios grupos y cruzando conversaciones hacer un backup de todo me resulta primero complejo de imaginar de forma ordenada.

¿Y podrías entonces descargar todos los contenidos de otras usuarias si supieras sus contraseñas?

¿Y como sería visualizar el contenido descargado? ¿habría que volverlo a instalar en otro elgg para poder verlo ordenadamente o bastaría con la terminal para el que sepa usarla?

O le dedico tiempo a hacer estas reflexiones o a leer sobre como la gente debe limpiarse el culo. No se por donde seguir inspirándome.

¿Como puedo expresar gratitud por lo que has escrito siempre? Pero las que te hayan leido antes atentamente ya conocían la relación de acontecimientos que has percibido al haberlo explicado otras veces. ¿Para cuando un debate técnico y en inglés sobre problemas concretos? Podemos dinamizar eso mientras cada una se limpia el culo como pueda. O hacer nosotras lo mismo y liarnos a dedicarle a la misma cosa el tiempo que le prestamos atención al grupo lorea de n-1.

Entonces, por sistematizar:

1) El plugin debe distinguir entre documentos públicos y privados y gestionar la descarga acorde con el habitante que la solicita y sus privilegios.

2) Ofrecer una interfaz de usuario para añadir/quitar los documentos que serán incluidos.

3) Los documentos exportables habrán de cubrir todos los módulos de datos de Lorea, desde telegramas hasta las páginas de las wikis, pasando por enlaces, fotos, páginas, etc.

4) Casos concretos a estudiar (ordenados de menor a mayor complejidad):

— a) Telegramas

— b) Enlaces

— c) Fotos

— d) Vídeos

— e) Tareas

— f) Páginas

— g) Calendario

— h) Blogs

— i) Wikis

— j) Grupos

— —  j.0) Elementos anteriores

— —  j.1) Discusiones, módulo asambleas.

— —  j.2) Lista de correos

 

 

Responder

  • aleph

    aleph

    hace 3 días

    Brainstorming This is to list proposed perspectives to achieve the backup per inhabitant plugin goal.

     

    Summerizing current possibilities:

    • APP like by caching content offline
    • REST-API like client/webservices
    • Pseudo-admin back up
    • Generating compressed file “on the fly”

     

    1) APP like by caching content offline

    There is some kind of “A secure, offline-capable, mobile-first web client for Elgg built with AngularJS.” on https://github.com/ewinslow/ng-elgg where an APP model gets in the scene, on Elgg Comunity forums, we can read main points:

    • View logic is rendered on the client, therefore not burdening server CPU or memory.
    • The app’s assets will be cached offline, therefore not burdening the server with requests for the same assets on repeat visits.
    • The app’s assets are cached offline, so users startup experience in many cases is bounded by JS parse and execution time, not network RTT and server response time. If you don’t have the data cached offline yet, then you do still need to take the network hit, unfortunately.
    • The app’s assets are static, so no need for PHP to run when they’re first requested.
    • It will be trivially easy to make sure that all assets are minified and compressed, including optimizing images and minifying HTML templates.
    • Everything is executed async and as-needed with RequireJS/AMD to minimize JS parse/execution time, instead of loading the WHOLE app in 1 giant JS file up front, which would kill startup time on mobile because Elgg is HUUUGE. Only the minimum JS for the current page is run, then as you load more pages more JS is loaded to work in those pages. It’s really quite cool if I do say so myself.
    • Even entities and lists of entities will be cached offline so users will be able to get stale data in a few milliseconds (effectively instantly). That data is then updated in the background from the server.

    2) REST-API like client/webservices

    The idea here is to use some JS/HTML/CSS user interface to display data that is pulled from Elgg webservices by using user authentication and api key. There is an already developed plugin based on this: https://www.marcus-povey.co.uk/2009/08/25/using-elggs-rest-like-api/ , that could be used as a model. In developer’s own word, the process (for newbies) should go as:

    • expose a function as a web services method and get it working without any authentication from a web browser
    • start calling the method from a client application on your computer (PHP cli, Python, Java, etc). You can take a look at the client libraries put together for Flickr or Twitter for an idea of how to build a simple client
    • add authentication – first API and then user
    • move to the client.
    • build out your web services API and the client application

     

    3) Pseudo-admin back up

    Another approach, mainly for advanced inhabitants, could be the customization of a generic admin backup plugin like https://community.elgg.org/plugins/1329896/releases/1.0 to perform a selective and dedicated backup that user could recreate on another installation.

    4) Generating compressed file “on the fly”

    By the way, it seems a lot easier, some kind of only one-time-use approach combining 1) and 2) just looping on inhabitant profile and generating some XML file that can be downloaded to be consumed offline. Here we are thinking on Twitter backup request example.

    Backup process should create a unique compressed file consisting in static HTML5 (XML) plus content folder (images, etc.)  and the plugin should take care about storing quote on disk and downloading dead line.

     

    Responder

    • aleph

      aleph

      hace 2 días

      By approaching what seems to be the easiest way to get the plugin: 4) Generating compressed file “on the fly”, here it is some very generic overview of the flow and element steps.

      We consider a “Backup Class” which would take care of coursing backup orders; and a “Backup Cron” which would manage the orders:

       

      Responder

      • aleph

        aleph

        hace 2 días

        [English]

        Rollero and Aleph find each other on 17/03/2015 irc#lorea meeting.

        Rollero says that this plugin is not worth for current Lorea version. But he says that bithub sounds good. He also makes Aleph to notice that a Group belongs to an Owner rather to an inhabitant, and he dares to coders the possibility to manage that.

        Aleph tells Rollero that there are some inhabitant needing this plugin and that this could be a reason to develop it. He also explains that if there were some quorum in the lorea-reloaded-spring-summer-autumn-2015 semipermanent hackathon the task list could grow and be priorized.

        [Spanish]

        (20:04:00) rollero: q tal aleph?
        (20:04:46) aleph: Very good, pero un poco mojao que ha caído una buena esta tarde!!!! y vos?
        (20:08:38) rollero: ah yo bien por aqui
        (20:08:45) rollero: estaba leyendo lo de bithub
        (20:08:56) rollero: mola, no sabia, tengo q leer mas
        (20:09:07) rollero: yo abri un hilo hace mil sobre eso
        (20:09:56) rollero: bueno, me imagino tambien una manera mas simple y cutre de atacar el asunto
        (20:10:17) aleph: Molaría recopilar la info en el hilo para ver qué opciones…
        (20:10:32) aleph: mañana, creo, dispondré de un server para intalar una demo… para cacharrear…
        (20:10:51) rollero: con un formulario y checkboxes ya podria valer.. pero mextraña q no haber oido lo de bithub en faicoop o coopfunding
        (20:11:13) rollero: vaya q bien
        (20:11:48) rollero: voy a ver q dicen en el grupo de coopfunding
        (20:16:19) rollero: ah, el tema de bithub crees q es mejor solo para software libre activista?
        (20:17:32) aleph: Bueno, en verdad, siempre, pensando en máximos-utópicos, lo genial sería desarrollar nuestro propio gestor de micropagos… Bithub solamente es un servicio que conecta github con coinbase…
        (20:17:53) aleph: molaría poder conectar repositorios de gitorious o redmine con carteras darkwallet… and so on…
        (20:18:42) aleph: Y del plugin para backups de usuarios qué opinas? algunan idea de cómo abordarlo? https://n-1.cc/discussion/view/2095202/lorea-reloaded-spring-summer-autumn-2015-plugin-inhabitant-backups
        (20:20:27) rollero: estaba pensando en eso del dw si, y creo q lo del funding iba para la 1.0 si. en un par de dias o tres digo algo por alli por el foro
        (20:20:46) rollero: lo de la data
        (20:21:01) rollero: claro q mola, pero no lo veo para desarrollar en elgg

        (20:29:49) aleph: como te oiga Efecto99 decir que el plugin este no hace falta te ata los testículos con hilo de púas y te los aprieta hasta que te efundan los líquidos primordiales… ;.D
        (20:29:54) aleph: 😀
        (20:30:26) rollero: 😛
        (20:31:00) rollero: para mi la prioridad de hacerlo en elgg es bajisima..
        (20:31:04) rollero: para mi eh
        (20:31:32) aleph: qué significa la abreviación que has puesto arriba: dw?
        (20:31:50) rollero: es que encima el content added to the group belong to the group (owner)
        (20:31:54) rollero: darkwallet
        (20:32:25) aleph: 😛
        (20:32:26) rollero: bajarse lo publicado desde un user en su profile igual es facil, pero lo otro debe ser chungo de testiculos
        (20:33:29) rollero: ei podriamos empezar por tener una direccion de bitcoin para lorea y otra para n-1, q tal?
        (20:33:44) aleph: Bueno, si sale quorum para ese “Lorea Reloaded Spring-Summer-Autumn 2015 semipermanent hackathon” que propongo podemos listar tareas y poner esta en el grado de prioridad que el corresponda…
        (20:33:45) rollero: bitcoin y etcrypto mas
        (20:34:01) aleph: Creo que ya la tienen…
        (20:34:21) rollero: ah voy a checkear
        (20:34:27) aleph: me parece que figuran en la portada del grupo:
        (20:35:04) aleph: https://n-1.cc/pg/groups/11605/sustainability/
        (20:35:18) rollero: 1PsJRjeThvsJuRBxf3hnzQjH16MPA8cMmU
        (20:35:59) rollero: hay q darle mas visibilidad
        (20:36:13) rollero: tanto para eldonante como para el participante
        (20:36:23) rollero: sabeis algo de la web lorea.org?
        (20:37:33) rollero: podemos hacer una cuenta cryptocoin para n-1 pim-pam
        (20:37:59) rollero: y lo ponemos en la web n-1.cc
        (20:38:02) aleph: de la web parece que hay algún problema de certificados… https://n-1.cc/discussion/view/2080888/loreaorg-re-visited
        (20:39:35) aleph: De esos que dice de la moneda, en el grupo “sustainability”, Binge propone crear una moneda para n-1: https://n-1.cc/discussion/view/2087615/sostenibilidad-de-n-1-2015
        (20:40:37) rollero: que cabeza pondria el contenido solo para usuarios logueados por defecto?
        (20:40:51) rollero: no me puedo loguear ahora para verlo.. 🙂
        (20:41:11) aleph: Vaya… eso sí que es fácil de cambiar en el panel de admin…
        (20:41:15) rollero: en cuanto pueda lo cambio a publico por defecto en n-1
        (20:41:27) aleph: ¿tú eres admin?
        (20:41:35) rollero: pero tengo q pillar a un admin desprevenido 😉
        (20:41:42) aleph: 😀
        (20:41:49) rollero: yo no, ni operator
        (20:42:04) rollero: mi unico privilegio es ser creador de tareas en el grupo n-1

        Responder

        • blinge

          blinge

          ayer

          nice!

          Da gusto encontrar a fin algo de feedback. Así dan más ganas de seguir rompiéndose el tarro.

          Veréis. Creo que hay que renovar las cuentas de paypal y de bitcoin del capítulo de donaciones de lorea. Ahora mismo está un poco desordenado el asunto.

          Cuando hayamos hecho eso estoy de acuerdo en volver a darle más visibilidad.

          Responder

          • aleph

            aleph

            ayer

            [English]

            As Blinge quote about current task list priorities, Aleph & Blinge agree with to pull the plugin in the array over the calendar.

            Also, about first perspective above: 1) APP like by caching content offline, …  here there is an ataching: «a nine-frames gif about ng-browser and the evolution of serverMVC to APP paradigm» just to hold in the wall a two minutes speech introduction. Gif’s frame duration is intended to be remarked a time-extension speech pulse while dealing with the microphone.

             

            APPCache, Client-rendered, chrome-style updates, AMD managing dependencies, auth-as-a-service, package managers, task runers

            [Spanish]

            Veréis. Creo que hay que renovar las cuentas de paypal y de bitcoin del capítulo de donaciones de lorea. Ahora mismo está un poco desordenado el asunto.

            Cuando hayamos hecho eso estoy de acuerdo en volver a darle más visibilidad.

            Vale. Ya se abordará en su momento, entonces. He estado mirando sobre la primera opción: 1) APP like by caching content offline.

            Responder

            • aleph

              aleph

              ayer

              [English]—-

              Aleph brings here some mail reply to an specific demand about caching content in client-rendered and appcachebased auth-as-a-service browsers managing dependencies and packages and running tasks.

              The guy that is emailed by Aleph, answers by saying that it good to be nice window to use: 2012, de Archibald[1]: Application cache is a douchebag, article.

              He also makes some naif joke with current politiks star in Spain’s panorama.

              [Spanish]

              Uno de los juegos más gustosos que tiene Pablo Iglesias en sus tertulias, en un claro alarde de juego con el poder, ya sito en la tertulia en el papel de moderador omnisciente, es el de echarle el cabo a los tertulianos diciéndoles: «Si yo fuera el presidente de la nación y vosotros mis asesores en [tal o cual materia que se está debatiendo], en “regla del minuto”, en sesenta segundos: ¿qué me aconsejaríais?»

              Pues bien, Aleph, yo aquí, siendo tú el moderador que aguarda mi punto de vista, mi visión-lógica del asunto, si tuviera que asesorarte en un minuto sobre cual es el estado de la cuestión APP en términos generales, tiraría de artículo de 2012, de Archibald[1]: Application cache is a douchebag.

              Por ahí que se puedan abordar otros temas a partir de esa ventana.

              Básicamente explica «el terreno sobre el que las APPs se asientan, arrojándose desde los servidores de html». Da un poco de contexto técnico, tres años atrás, de un proceso que ahora, en tu demanda, se hace vigente: «la necesidad de dotar a los dispositivos móviles de potencia de almacenamiento y autonomía. La explicación tecnológica de este proceso de emancipación de las app como móneras soberanas que se interconectan en ecosistema punto a punto» se hila en una serie de tecnologías y de tipologías de códigos que participan en el proceso. Sobre todo cuando ese, digamos descenso desde el platónico mundo de servidores LAMP, dota de sustancia a un fragmetario cuerpo de particulas flotando entre la WEB y la DEEP WEB.

              Si te veo en persona te lo comento en unos minutos. Vamos mirando. Corto y cambio. ¿Sigues con el blog de los mosqueteros y del Dartañan?

              [1] http://alistapart.com/article/application-cache-is-a-douchebag

              Responder

    • aleph

      aleph

      hace 56 minutos

      [English]

      Concerning above brainstormed option:

      1) APP like by caching content offline

      … and on the context of: the hackathon called “Lorea Reloaded spring-summer-autumn 2015″… Some rocking girl gives advice to Aleph by saying:

      «… a naif coder would see the magic on his hands while trying to approach “inhabitant backup Elgg2dot0 plugin” in a way as you request; the naive coder can think that this plugin is posible by such fucking great controller unsystem people have built; take a look on repo:

      https://github.com/darkwallet/darkwallet/blob/develop/src/js/frontend/controllers/backups.js »

      “Tell me, what?!!!” — this is shouted by Aleph– “This is crazy!!!! Ain’t it!”

      Can you imagine an APP where this frontend could use this controller… let’s say:

      https://github.com/lorea/lorea_backup_holder/blob/develop/src/js/frontend/controllers/backups.js ?

       

      [Spanish]
      En el contexto del hackathon semipermanente «Lorea Reloaded primavera-verano-invierno 2015» y del plugin para Elgg2.0 “copias de seguridad para habitantes”, un coder perdido en la inmensidad de la impotencia podría escuchar la voz de conseja que una rocking twitt star le da en rebote de su petición, apuntándole a encontrar la panacea en semejante controlador de backups dentro del frontend js de la darkwallet (que, por cierto, van por la 0.8.0):

      https://github.com/darkwallet/darkwallet/blob/develop/src/js/frontend/controllers/backups.js

      … y, viéndolo, junto con la clase de entrada a la API js –la rocking twitt star le señala–:

      https://github.com/darkwallet/darkwallet/blob/develop/src/js/darkwallet.js

      “¡Sí se puede, sí se puede!”–exclama Aleph. Cree que puede crear ese plugin…– “¡Sí se puede!”

      (¡¡¡Someone could help this fucking naive, naif coder. Little fnordian son of Eris!!!)

      ¿Alguien más se imagina un:

      https://github.com/lorea/lorea_backup_holder/blob/develop/src/js/lorea_bup_hold.js

      ?

       

      Responder

      • aleph

        aleph

        hace 16 minutos

        1 image

        AppCaching, in client rendered UI’s, is good! HTML5 can manage offline scenarios…

        2 image

        It would be good to start a list: what do I need to learn?

        3 image

        Then, it should be nice to become self-explained

        4 image… become self-explained so we are able to avoid off-the-record-voices. And so on…
        6 image

        A libido-sintetic poszizekian tutorial!

        7 image

        Ok. Clear enough: no more of the record voice.

        8 image 9 image
        10 image 11 image
        12 image 13 image

        Responder

Lista de correo

Recibe los mensajes de los foros en tu correo y envia mensajes directamente contestando desde tu email.

Suscribirse

Anuncios