Nostr Web Client

For a site like yours franzap, a store with products, the hierarchies of context would include things like: Alice trusts Bob to provide reviews of zap.store products in the category of electronics, with smartphones being a subcategory of electronics. As the app developer, at first you would create the hierarchy of categories yourself. Eventually, the hierarchy of categories would be curated by the Grapevine. The tapestry protocol shows how to do all of that, in detail. I’ve already used it to curate lists, and curating a graph is going to be conceptually not much harder than a list.

But we need to take baby steps, which is why at first, you as the dev should manage the hierarchy of categories yourself. There are other ways to break it down into baby steps from a dev perspective. I’d love to brainstorm with you and hammer out details on how you could do that with zap.store if you’d like. 😃

franzap 1y ago

Sorry I was never notified of your messages! I am getting your idea of the web of trust now. Totally on board explicit trust attestations and that zaps, likes, etc are useless because they can be gamed.

I'm on the fence re: hierarchies in practice as it seems useful but hard and rigid (even starting with baby steps). Had a look at tapestry and it looks interesting but definitely a rabbit hole in itself, I'll have to dive into it later. I fear making this even slightly complex will result in little traction.

My current idea revolves around simple trust attestations ("vouching for someone", I attest to the best of my current knowledge that this person has integrity - they're not a scammer or a psycho). Optionally with a few generic categories like (a) known them for years, (b) met them in person, (c) known them online, etc. I have ideas for UX around the creation of such events.

My current thinking is that hierarchy is an orthogonal concept, like if they know a lot about plumbing but nothing about cars or developing apps. Putting those two things together (hierarchy + trust) has to be probably done at the point of decision (which is how we do it IRL) and not be pre-calculated, and can be helped by (wot-filtered) reviews which are instantiations of both.

Reply to this note

Please Login to reply.

Discussion

david 1y ago

Regarding complexity: the Grapevine as I envision it is VERY complex for the developer, but it can be made as simple for the user as we want it to be. The Grapevine has lots of parameters that users can adjust, and a common question will be when to give the user the option to adjust some parameter vs when to set some default value and hide it. Too many options can be overwhelming. But these parameters will be essential when the invariable sybil attacks and bad actors try to infiltrate your Grapevine. It will take some mad design skillz to know how to unveil some of these options when the time is right.

Regarding hierarchies: the long term plan will be that your Grapevine manages all hierarchies for you, unless you want to roll up your sleeves and dig into it yourself. Most users will not want to spend the time and effort editing hierarchies, UNLESS they want some category(ies) to exist that have not yet been submitted and placed into the hierarchy. In that case, many users will want to roll up their sleeves and get it done, but once the hierarchy is properly edited and a few users endorse the changes (assuming they’re reasonable), then the entire world will benefit from your work and no one will have to repeat it.