138 lines
No EOL
5.2 KiB
Markdown
138 lines
No EOL
5.2 KiB
Markdown
# Ideas
|
|
|
|
Notas e ideas sobre la futura guild.
|
|
|
|
## Objetivos
|
|
|
|
- Crear un espacio de libre comercio al margen del estado
|
|
- Promover un sistema paralelo de:
|
|
- Registro de propiedad
|
|
- Resolucion de conflictos
|
|
- Sistema de identidad de personas fisicas y juridicas
|
|
- Crear un walled garden con skin in the game que promueva el trust entre los miembros
|
|
- Agrupar a gente con valores similares:
|
|
- Algun vinculo con Barcelona
|
|
- Soberania
|
|
- Libertad
|
|
- Capitalismo
|
|
- Individualismo
|
|
- Objetivismo
|
|
- Low-time preference
|
|
- Antidemocracia
|
|
- Privacidad
|
|
- Valores Cypherpunk
|
|
|
|
## Tamaño
|
|
|
|
- Hardcap a 100 miembros? Mil? Cuanto es demasiado?
|
|
- Como superar el bootstrap inicial? Cuando no hay socios, cuesta atraer a gente de calidad, pero si los primeros miembros no son de calidad, es dificil hacer la red atractiva
|
|
-
|
|
|
|
## Democracia vs Dictadura
|
|
|
|
Quien es el propietario de la guild? Quien tiene las riendas? Quien puede decidir? Quien puede expulsar?
|
|
|
|
Dos planteamientos opuestos:
|
|
- Asociacion
|
|
- una persona, un voto.
|
|
- Se establece una constitucion basica que rige la gestion de la asociacion y los principios regulatorios mas inquebrantables. Esta constitucion deberia ser casi immutable (unanimidad absoluta o mayoria clamorosa para cambiarse).
|
|
- Se establecen cuerpos operativos para el trabajo, con miembros electos por los socios.
|
|
- Transparencia total en la gestion de cuentas.
|
|
- Gestion privada (Dictadura benevolente, para entendernos):
|
|
- una sola persona tiene el poder completo.
|
|
- La persona mantiene el control absoluto. Impone las normas segun le parece. Los miembros solo tienen el poder que les proporcione la dictadura
|
|
- La buena fe y calidad del gobierno depende de cuanto de benevolo e ilustrado sea
|
|
|
|
Hay una fuerte relacion entre esto, el control de las claves PGP que identifican a la direccion y los canales de comunicacion, el control de las claves de BTC que regulan los depositos y el control de la infrastructura de IT que lo soporta todo. El derecho natural aplica, y la direccion de la guild, sea democratica o de gestion privada, debe proteger el control sobre estos elementos para garantizar su existencia y que no la tumben los barbaros, vengan de dentro o de fuera.
|
|
|
|
Otras pregunta añadida:
|
|
- deberia la guild tener animo de lucro?
|
|
- Que nivel de transparencia deberian tener las cuentas?
|
|
|
|
## Identity and safety
|
|
|
|
Cada individuo en el grupo necesita una identidad clara y reconocible cuando se comunica. Esto es un principio basico de cualquier marco regulador: sin la abstracion de la persona, no podemos montar nada.
|
|
|
|
Por suerte, la solucion es facil: cada miembro debe tener una clave PGP que le permita firmar mensajes. Esa es su identidad y su firma. Sera un desafio de UX que la gente se tome con la gravedad necesaria la preservacion de sus claves. Probablemente habra que hacer trainings, y tenga sentido regular un USB con tails y una Yubikey/Nitrokey/Openkey.
|
|
|
|
Las comunicaciones importantes deberian firmarse y encriptarse. Los contratos entre los miembros deberian firmarse con sus identidades para tener valor.
|
|
|
|
|
|
## Servicios
|
|
|
|
- Resolucion de conflictos, intermediacion en contratos y escrow
|
|
- Acceso a infraestructura IT
|
|
- Lightning
|
|
- Comunicacion interna y videollamadas
|
|
- Custodia colaborativa
|
|
-
|
|
- Servicio de asistencia en herencias
|
|
- Servicio de asesoria fiscal (delegado en Jose Antonio Bravo)
|
|
|
|
Ideas particulares mias
|
|
- Servicio de carne y huevos
|
|
- Servicio de alquiler moto
|
|
- Servicios de fisioterapia
|
|
|
|
## Procesos, reuniones y ceremonias
|
|
|
|
### Inclusion de nuevos miembros
|
|
|
|
- Como seducir sin hacer proselitismos
|
|
- Tiempos y pasos del proceso
|
|
|
|
### Comunicaciones regulares
|
|
|
|
Boletin mensual (deberiamos usar ciclos de bloques en lugar de mensuales?) con anuncios oficiales y anuncios de miembros
|
|
- Nuevos miembros, bajas de miembros, penalizaciones, elevaciones publicas de contratos
|
|
|
|
Cada boletin deberia ir firmado y con sus contenidos hasheados junto al hash del bloque correspondiente.
|
|
|
|
Boletin anual (deberiamos usar ciclos de bloques en lugar de anuales?)
|
|
|
|
### Cambio de normas
|
|
|
|
- Consulta a los miembros
|
|
- Debate publico
|
|
- Anuncios finales
|
|
- Ciclo mensual, anual y por epoch
|
|
|
|
### Salida de miembros
|
|
|
|
salidas voluntarias
|
|
- Como evitar traiciones y denuncias de cara al estado?
|
|
expulsiones
|
|
|
|
### Proceso de multado
|
|
|
|
- Como penar a alguien?
|
|
- Deberia la asociacion recaudar?
|
|
- Deberia repartir el dinero entre los miembros?
|
|
- Deberia quemarse el BTC mandandolo a una direccion aleatoria?
|
|
|
|
## Infraestructura
|
|
|
|
- Servidor de Git
|
|
- Servidor de PGP?
|
|
- https://pks.sourceforge.net/
|
|
- Repositorio estilo wiki y de documentos
|
|
- Almacenamiento cloud encriptado para guardar claves de deposito y otros secretos
|
|
- Nodo de lightning + LNBits o similar
|
|
- Servidor de Jitsi
|
|
- Servidor de Element/Mattermost/comunication channel. Hay que encontrar algo que sea criptograficamente solido como una piedra pero no tenga una experiencia de mierda. No pasa nada si necesita un servidor central.
|
|
- Stacker.news? Algun sitio donde la gente pueda crear announcements
|
|
|
|
|
|
## Problemas abiertos
|
|
|
|
- Que hacer contra un chivato de cara al estado?
|
|
- Que hacer en caso de que un miembro de la dictadura quede deshabilitado?
|
|
|
|
|
|
|
|
## Otros
|
|
|
|
- Tiempos en blocktimes
|
|
- 210,000: cuatro años
|
|
- 52,500: un año
|
|
- 4,375: un mes |