Decentrale apps

Forøjeblikket går jeg med nogle overvejelser om hvordan jeg bedst bygger apps. Hermed et forsøg på at forklare nogle af disse på et ikke-teknisk sprog.

En app kan være mange ting. For mig er en app et lille program, der kan kører på en telefon, eller i en webbrowser / computer. Denne slags apps kaldes også web-apps eller hybrid-apps. Når jeg laver apps på denne måde, skriver jeg kun app’en en gang, og så kører den på alle telefoner og computere. Dette står i modsætning til rene native-apps, som man laver specifikt til én type telefon, og som til gengæld kan virke mere polerede.

Ved udvikling af apps, skal der ofte laves to programmer: 1) selve “klient”-app’en der kører på telefonen eller lignende, og 2) “backend’en”, der kører på en server. Backend’en bruges til at dele informationer mellem klienterne. Forøjeblikket går jeg med overvejelser om, hvordan man kan lave apps, uden backends. Første trin er, at lave én generel backend, som kan bruges til at lave forskellige apps. Andet trin er at lave backend’en “distribueret/decentral”. Med distribueret mener jeg her et program, der ikke kører på en central server, men i stedet kunne køre på flere servere, eller endda kører på klienterne uden server.

Der findes allerede generelle backends, hvor man ikke skal skrive et nyt serverprogram for hver app. Eksempler er http://nobackend.org/, firebase(proprietær) http://hood.ie/ (opensource), og flere andre. En generel backend skal typisk håndtere login (authentificering), kunne gemme data, og koordinere kommunikation mellem klienter. Disse backends kræver stadig en central server.

Nogle fordele ved decentrale systemer er: 1) det er ikke muligt at bryde ind i én serveren og få adgang til alle data, 2) brugerne kan ikke overvåges på samme måde, 3) serveren er ikke en flaskehals i forhold til performance.


En af udfordringerne ved at gøre dette decentralt er sikkerhed og adgangsstyring. En central server, med adgang til alle data, kan let styre og give klienter adgang til de data, som klienterne må arbejde med. Hvis der ikke er nogen central server, skal sikkerheden i stedet være bygget ind i data, hvilket er sværere.

Begrebet sikkerhed dækker over flere ting: at kunne logge ind, adgang til at kunne læse data, authentificering af hvem der er ansvarlige for data, adgang til at kunne ændre data, etc. Hvis man har en central server, kan den bestemme og styre dette. I decentrale systemer kan dette udføres via “public/private-key kryptering”.

Grundkonceptet i “public/private-key kryptering” er, at der er to kodeord/nøgler. Efter at man har brugt det ene kodeord til at gemme data, så kan man kun læse data igen, hvis man har det andet kodeord. Dette er kan blandt andet lade sig gøre, via noget matematik med nogle store primtal, som jeg ikke vil forsøge at forklare her. At gemme data på denne måde, er et eksempel på at kryptere data. Ofte kalder man det ene kodeord for den offentlige nøgle, og det andet kodeord for den private nøgle.

Via kryptering, kan man have sikkerhedsfunktionaliteten uden en central server:

  • Login, er det samme som at kende den private nøgle. De offentlige nøgler kender alle.
  • Adgang til at læse data, gives ved at data krypteres, så de kun kan læses hvis man har den private nøgle. Data kan sendes til en anden bruger, så det kun er hende der kan læse det, ved at kryptere det med hendes offentlige nøgle.
  • Du kan underskrive data, ved at kryptere data med din private nøgle. Andre kan tjekke din underskrift, ved at dekryptere data med din offentlige nøgle. Derved véd de, at det er dig, som har underskrevet data.
  • Adgang til at skrive data kan styres ved at ændringer i data skal være underskrevet af den, der ejer data.

Ovenstående beskrivelse er på et konceptuelt niveau, – for at det fungerer effektivt skal man også bruge “kryptografiske hashes”, “symmetriske cifre”, etc. hvilket er for langt, til at beskrive i detaljer her.

Der er også andre udfordringer ved at lave en decentral backend. IPFS løser nogle af disse. “Konflikt-frie replikerede datatype” løser andre aspekter af det. Alt i alt: det tekniske fundament til at bygge decentrale apps, ser ud til at være stabilt indenfor de næste par år.


Et projekt jeg godt kunne finde på at lege med er: at lave en generel backend, som er designet, så den på længere sigt kunne laves om til at være fuldstændigt decentral.

Første trin er, at definere den ønskede funktionalitet. En minimalt og lidt forenklet oversigt over påkrævet funktionalitet er:

  • Login
    • Brugeren skal indtaste kodeord eller logge ind via af andres services.
    • App’en får en privat nøgle og en offentlig nøgle tilbage. App’en kan også selv lave midlertidige nøgler.
    • App’en kan bevise at den offentlige nøgle faktisk er brugerens.
  • Gemme data
    • Givet privat nøgle, navn på data og dataindhold, skal data gemmes.
    • Givet offentlig nøgle og navn på data, skal dataindhold returneres.
  • Kommunikation mellem klienter
    • Givet en privat nøgle kan man abonnere på beskeder.
    • Givet en offentlig nøgle og en besked, vil beskeden blive sendt til en af abonnenterne med den matchende private nøgle.

På dette fundament vil man kunne bygge rigtig mange typer apps, helt uden backend. Og øvrige typer apps, hvor det blot kræver at en særlig backend-bruger altid er logget ind mindst ét sted.

Dette er muligt implementere decentralt på en effektiv måde (når en decentral infrastrukturen er klar, og med visse teknisk detaljer om synkronisering af datatype). Allerede nu, vil det relativt enkelt kunne implementeres med en central server, der senere kan erstattes af et decentralt system.

At udtænke detaljerne hvordan / hvorfor / om dette hænger sammen, er et eksempel på den type intellektuelt “arbejde” som jeg holder af at dykke ned i for sjov. Dette er også et konkret eksempel på et af de projekter, som jeg tænker at prøve at bygge i praksis på et tidspunkt.