You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in the interest of practicality, i'm not aiming to achieve the ssb utopia where every agent (person or group) manages their own keys, their own feed, ☀️ and 🌈. rather, there should be a spectrum from the current way apps are deployed (on public servers controlled by a single agent and isolated from other servers' data) to the utopia, so developers can slowly migrate their users without interrupting the existing service.
some terminology:
agent: a person or a group
member: an agent who is part of a group
host: an agent who runs a pub server that manages feeds for its members
every agent should have complete control of their data and how it is shared. they have to trust their host (either them or a group they are a member of) who actually stores the data to enforce their control.
i've been thinking about nodes as agents, which includes people or groups (or projects which i think are short-term groups). then, as not every agent wants to host themselves in the network, group agents can host their members. we can achieve federated querying amongst network-of-networks with http://linkeddatafragments.org/.
in our current use case, Enspiral would be a host agent for the people and groups within Enspiral. however, any of these members may be their own host, thus creating a federated mesh of hosts where each host has access to all the data of entire network of agents. for the Holodex implementation, i imagine "being a host" would be running the Holodex app on a public server, where we use scuttlebot as a backend to handle data operations (on each agent's feed), replication (across hosts), and queries (linked data), which we use to export a standard http / websocket api interface.
so, @dominictarr, some documentation on how to use scuttlebot as a backend for a data api would be magical. ✨
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
to throw some spaghetti at my suggested product angle, i'm curious to see if it's possible and/or practical to use scuttlebot as a backend database, as with holodex [demo] at the moment i'm planning to re-build our data api.
in the interest of practicality, i'm not aiming to achieve the ssb utopia where every agent (person or group) manages their own keys, their own feed, ☀️ and 🌈. rather, there should be a spectrum from the current way apps are deployed (on public servers controlled by a single agent and isolated from other servers' data) to the utopia, so developers can slowly migrate their users without interrupting the existing service.
some terminology:
in our current use case, Enspiral would be a host agent for the people and groups within Enspiral. however, any of these members may be their own host, thus creating a federated mesh of hosts where each host has access to all the data of entire network of agents. for the Holodex implementation, i imagine "being a host" would be running the Holodex app on a public server, where we use scuttlebot as a backend to handle data operations (on each agent's feed), replication (across hosts), and queries (linked data), which we use to export a standard http / websocket api interface.
so, @dominictarr, some documentation on how to use scuttlebot as a backend for a data api would be magical. ✨
The text was updated successfully, but these errors were encountered: