Good job!

Question: Are you providing any kind of proofs client apps can easily check to be more certain that Vertex is not lying?

Or even better: with the request one could add some params as to how or what kind of proofs should be provided by such dvms, depending on use-case.

I might sound vague but you get the point I hope.

Reply to this note

Please Login to reply.

Discussion

yes this is something we definitely want to explore in the future.

One idea, specific for recommend follows, is to provide some kind3s (or their IDs), so the user can verify client side if and how he's connected to all the recommended npubs. We are talking about 2N +1 kind3s as the worst case where N is the number of recommendations.

nostr:nprofile1qqst3axzay8sm4n8zg2n84acmt7hwwztpdg9r7p89e2f83v007f7zjcprpmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet5qyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq7lw5g starks to the rescue?

Could be an option.

We started some experiments to see how starks could be useful for Nostr.

Right now we are focused on delegate signature aggregation verification.

https://github.com/keep-starknet-strange/starkstr

That's a cool use case!

This is a smart idea and could really save a lot of storage space & bandwidth for relays. Weโ€™d be happy to implement it in nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g when itโ€™s ready. ๐Ÿ

Try the relay dashboard demo here!

https://hornetstorage.net

You keep going .. itโ€™s impressive !

I still have problem to handle some uses of starknet but itโ€™s fault ๐Ÿ˜