Working on the Small Web place creation flow and its related protocols.

The goal is for it to be as interoperable as possible. We have to work with external server, DNS, and payment providers and, in addition, we want people to be manage their hosting subscriptions on their own places. The providers own APIs will be abstracted with adapters.

Why all this? So you can set up a small web place in 30 seconds without getting locked into any one host.

· · Web · 4 · 6 · 12

@parlehaakon Thanks, Haakon. From a quick skim, these seem to require a 3rd-party to create the signatures (unless I’m mistaken). Since the small web is single-tenant and private key material is only ever kept on the client, I’m not entirely sure they’re directly applicable. It’s important for the small web that any action taken on behalf of the person comes from the person. So I’m using a token that’s encrypted with their public key and decrypted on the client. That said, are there any docs? :)

@parlehaakon (So I guess in Zot terms, a small web place is a single channel?) I don’t see why they couldn’t interoperate in the future as, at its core, you have a person that is in control of their own keys (although they don’t know it because it’s just a passphrase to them) and they have an always-on node that can keep messages for them, even if it can’t read the ones that are encrypted for them. And all messages are also signed.)

@Aral Balkan Yes, you could say a channel is similar to a small web place. A channel is a nomadic identity, so you can host it simultaniously at three or more clones if you like, content and interactions with others are cloned between your clones, so if one goes down, keep right on going from another clone. The small web place is only on the client, a Zot channel is on a server, either hosted at home or as part of a service.

@parlehaakon Cool, well I’ll definitely keep an eye on it. Always good to have multiple approaches and I’m sure there will be overlaps. I’m trying to get this from theory to practice as soon as I can and to pave the cowpaths from there. (Small web places do have a server component but we don’t trust the server insofar as that’s possible.)

@Aral Balkan Likewise. Spec for both OpenWebAccess or magic-auth cross domain authentication and Zot cross domain authorization are available in the first link under spec. See for implementations, or talk to @Mike Macgirvin .
@Aral Balkan I have a partial sequence diagram in the works, OWA is mostly done, Zot remains to be done. Hopefully done by the summer, too much going on. Now, home made pizza. :-)

@aral I love this diagram. Never represented things this way.

@c00kie It’s a sequence diagram. I find them indispensable for working through processes. I feel they’re generally rather underrated :)

@aral @c00kie yeah, those and bpmn are nice to spec out a (or describe an existing) process.

@aral Nice! 👍 (also +1 for using sequence diagrams, I've felt lonely promoting them at times) I was wondering, whether already the initial signup should require a payment/ subscription—or if this could/ should be something, one can upgrade one's place later (think: 14 days trial, whatever) 🤔 Don't get me wrong: I think it's absolutely essential for a place host to be considered a payed SaaS subscription. But maybe in terms of lowering barriers and in general easing the onboarding experience..

@matthiasgeisler Sure, how it’s implemented is up to the host. This is just an initial implementation. It doesn’t even have to be a monetary transaction. e.g., a city might mail out tokens to all its citizens that they can exchange for a small web place…

@aral Ah, ok. I get it. Also makes totally sense. Now I can even imagine a (local) "club (sport or girl/ boy scouts, ...); actually even a (public) school...

Sign in to participate in the conversation
Aral’s Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!