roadmapping

[serapath]

@todo

• initially make aybabtu a datdot testnet where tokens are called mana
  • aybabtu#2 API design
  • resolve & close https://dat.discourse.group/t/use-case-server-hosting-api/47
  • should include running a signalhub node to allow browsers into webrtc swarms
  • should include running a discovery-swarm-web server to help with DHT discovery
  • investigate requirements for (4. hosting provider server) and (B.) below
  • refine hosting concept
    • publish as npm module (standalone desktop app? and/or cli?)
      • play is supposed to be an application rather than a library, so it's probably not meant to be required in other projects, but it could be a command line tool which opens the project offline by starting a local browser or by being an electron app that runs play :-)
      • e.g. maybe inspiration from https://github.com/horizon-games/remix-app ?
• turn aybabtu into a real but experimental networkd over time

---

idea

• create a aybabtu, which is a modified homebase

  • (modified because admins might need to accept a "request to deploy/pin a certain dat" first

• a static landing page to allow a user to

  • one-click deploy an ayababtu to a server
  • see all deployed ayababtu instances
  • see for each instance which dat addresses are pinned by the deployed ayababtu instance
  • remote controlling/configuring ayababtu instances

• also aybabtu would publish itself to a public list of all ayababtu's

• public list - is a separate server which be configured with a particular filter function

  • it only adds data entries sent to it if the data entry passes the filter function test
  • like checking if for example an address data entry actually runs something (e.g. offers an API) that "quacks" like an aybabtu

• the user's private dat key lives in either:

  1. browser extension
  2. or web app's localstorage
  3. or dedicated iframes localstorage (same iframe on all web apps that want to use dat)
  4. or some more advanced mechanism in the future

---

important

• all other tools are supposed to be used in the browser
• all other servers are supposed to be deployed as server from clicking in the browser
• only the hosting part needs to run differently in order to enable above

There are four parts to the idea:

1. a standard for public server repositories, which includes a static "github page" where users can "one click deploy" to one ore more of the users list of bought/rented "hosting provider servers"
2. an open source static github page app which displays all currently bought/rented "hosting provider servers" available to the user and if and which standard adhering github repo they currently run and each servers status.
   • users can choose from a predefined list what software they want to run on it.
   • In the beginning, the only software in the predefined list a user can choose from when renting a server will be ayababtu
3. maybe a smart contract to manage the payments - think "AirBnB or Uber for hosting"
4. hosting provider server (=a software for for ppl to run to also become compatible hosters with their raspberry pi), a standalone image (maybe docker) for anyone to run on their own hardware or on AWS or Azure or digital ocean or a rasberry pi, etc.. connected to the internet to offer hosting in form of a VPS to "end users"
   • supports a buy/rent procedure to obtain "credentials" which can be used to control the server
   • as soon as it's up it exposes a API standard, which anyone can use to send it the address of a github repository (given the sender is "authenticated"), which adheres to a certain standard, which the VPS then clones and runs by executing some kind of startup script based on before mentioned standard
   • the API standard needs to be usable from browsers (e.g. http(s)? websocket? ...?)
   • ...furthermore the API could be used to generically start/stop/restart/status/... the server or whatever it was that got downloaded from the github repo
   • of course - also after the "server" was started inside the VPS, it might expose an additional API in whatever form that can be interacted with

B. We probably don't even need to offer renters to filter the marketplace by metrics such as uptime, network speed, geographical location, and hardware specs in the beginning, but we need an analysis if this is really the case and how we might design the first prototype to add those capabilities later on.

bootstrapping phase

• 1+ existing traditional cloud hosters to run the hosting provider server image to bootstrap the ecosystem in a way that the hosting service becomes a replaceable utility