%07VekPqfjZf5QWeok8Fu7ast8qkF5KEN1i1YpKUXctc=.sha256Content warning: ssb dev rabbit-hole
Design for installers blob web publishing.
Use a new message type to express mapping URL/paths to blobs. ssb-links has an index for this for link names in the mentions array, so use that. The mention name could have some prefix indicating it is for this application (like ssb-npm uses a "npm:" prefix), but if we use the fully-qualified URL, that is good enough and has a nice property of corresponding to what URL the blob should be served at.
Example:
{
"type": "installers",
"mentions": [
{
"name": "https://installers.scuttlebot.io/example/hello.sh",
"link": "&qNy5xZ4bhu61z4k+XenbtDnt1IJp0b/gLJ/vdzd5vxM=.sha256"
}
]
}
On the server side: serve the blobs as static files (e.g. using nginx), rather than having a ssb-server plugin/client serve requests. The reason is to have high availability, since ssb-server often hangs or crashes. Make a tool to sync changes from ssb messages to the file system, including a live mode. The tool should also have an option to publish blobs from the file system to ssb.
Can I get input/feedback on the security model? The simple implementation would treat as valid any message from anyone, like with ssb-npm and git-ssb. But I sense that people want a permissions structure. If using permissions, I am thinking to do it as follows: a new message type would indicate granting or revoking permissions to a feed for a path prefix/directory. Keep using ssb-links for the index, so indicate granting or revoking a feed access by mentioning the feed with the directory name. Example:
{
"type": "installers-grant",
"mentions": [
{
"name": "https://installers.scuttlebot.io/example/",
"link": "@ye+QM09iPcDJD6YvQYjoQc7sLF/IFhmNbEqgdzQo3lQ=.ed25519"
}
]
}
Then treat mentions in installers messages only as valid if their author has permission to the path, according to the installers-grant and installers-revoke messages. There also must be some "start of authority" for anyone to have permission to anything. For that, we could hard-code a set of grants, or allow for subjectivity by considering the current sbot id to have permission to the root level (all domain names). Possibly read additional permissions from the sbot config.
Variations on the idea:
- Have a fixed directory structure for permissions, like
<domain>/<group>/<project>/<version>/ - Drop the domain name and assume a single domain name for all paths. For the mention name, use a fixed prefix before the path, like "installers:"
- Have a simpler model where there is just one set of authors with permissions, no subdirectory permissions.
- Have a more general message type than "installers", if this is just a general-purpose permissioned file system.
- Represent directories with messages. Instead of specifying full URLs, specify the path in the current directory and reference the message representing the directory. This would allow for renaming or aliasing of directories. It also might help with subjectivity, by being based more on cypherlinks than a global URL space. It would allow for not depending on ssb-links if there is some initial mapping of domain names (or root namespace) to message ids for directories, since all other queries could be done via message backlinks.
- Rather than making new filesystem namespace thing, use/integrate an existing one like ssb-web, saljut, ssbdrv, git-ssb, or ssb-npm.
- Rather than a permission grant/revoke model, use a membership greet/shun model, as in Liquid Association / Completely Subjective Groups.
Other concerns:
- Would this be polluting the mentions namespace to use URLs to name blobs and feeds in mentions? The blob names might show up in Patchbay's blob summoner. Feed mention names I'm not sure if anything is using.
- There may be issues around state resulting from permission revocation. If someone's permission is revoked, should all their existing edits be considered invalid? Should a revocation mention their last "okay" message, so that future people can tell which of their edits were done before or after the author lost permission? (What if the author was granted permission by multiple authors and they revoked it at different times?) Should edits that have become invalid due to recovation be deleted from servers? Simple solution is don't delete anything in cases of revocation, and in cases of bad content, users can publish overwriting edits. This assumes source timestamps are reliable, for new people to compute the file system state. Simpler solution is don't have permission revocation. Even simpler solution is don't have permissions, just relying on the contact graph / ssb feed replication.
- Is permission management by grant/revocation messages the best approach? Other ideas: Liquid Association, Completely Subjective Groups, capability keys, reuse the social graph, use a new social graph.
- Is subjectivity important? In practice, for the current motivating use case (installer shell scripts on a web server), the system just needs to run on a single server. (It could be on more, even for the same domain name, but I don't know if there is any interest in that.)
I would like to find and implement a "simple as possible, but no simpler" solution. I also want to build on familiar concepts and ways of working - but a lot of those are centralized.
Related: Trusting the SSBC
published" message to acknowledge and announce new state