Here is my 2 cents for the questions:
1. App developers often make bugs, and for list events it means that it's easier to unwittingly erase the list if the user wants to add a new pubkey and cannot find the previous event on the network. Apart from that, it's easier to build graph from individual events (as VictorPamplona mentions in the github issue).
1.5 Replaceable events or static events? - Replaceable events can be updated, if trust relation changes over time. Also, event deletion seem to be not well implemented in relays.
2. Another model is private to the author + shared by relay/DVM when needed. I think the common sentiment is that we all see usecases for private trust events, but implementation is more complex. We need interactive protocol for this - as Hodlbod mentioned - or ZK proofs, and who knows what. For now, I think we should go for public, discover the possibilities and implement private model when we know more about the problem / we see what the main usecases are.
3. I would vote for an optional scalar "score" and "confidence" value. If they are absent, it's a binary true value.
4. I like the "context" term. I think it could be optional, but see a lot of value in embedding into the event, so as it can be used by filters as input. I don't see clearly what is the usecase for it derived by filters. Is it like "I trust this guy", and the algorithm tells me the context it was used in?
5. I'm probably not the one who has dig into it deeply. Not sure if this is what you mean by spec, but I'd like to know: what are the inputs/outputs, where the filter should be ran (client / relay / DVM / phone) and when (when content is created OR when queried). Should I be able to make a relay subscription based on a content filter?
Lez
npub1elt…cume
2024-03-30 12:37:30
in reply to nevent1q…vmh4
Author Public Key
npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cumePublished at
2024-03-30 12:37:30Event JSON
{
"id": "1d38a3b4e54d2e4ed3d01a3ff3b92dd42aa0162a02bd0471bdc362ff5eb7eb88",
"pubkey": "cfd7df62799a22e384a4ab5da8c4026c875b119d0f47c2716b20cdac9cc1f1a6",
"created_at": 1711798650,
"kind": 1,
"tags": [
[
"e",
"de8a97bc622006877c7881a9a69867a794395430fe8401bf0103992f9e3b4907",
"",
"root"
],
[
"e",
"b32fdfc20a8d3b328835ae5b6b4e145a2f3cffb7762055f1e9e04654ebf0fc92",
"",
"reply"
],
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
],
[
"p",
"df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200"
],
[
"p",
"cd868bf553cabfeef5ff89f9d34875210cdeda276ca4c6a3e7ffb7a31ab96447"
],
[
"p",
"e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f"
],
[
"p",
"cfd7df62799a22e384a4ab5da8c4026c875b119d0f47c2716b20cdac9cc1f1a6"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"633f317e99bc5a55c85d842784989a2bcdc31bea3c4c01fdfc80fd340facca3a"
],
[
"p",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11"
]
],
"content": "Here is my 2 cents for the questions:\n\n1. App developers often make bugs, and for list events it means that it's easier to unwittingly erase the list if the user wants to add a new pubkey and cannot find the previous event on the network. Apart from that, it's easier to build graph from individual events (as VictorPamplona mentions in the github issue).\n\n1.5 Replaceable events or static events? - Replaceable events can be updated, if trust relation changes over time. Also, event deletion seem to be not well implemented in relays.\n\n2. Another model is private to the author + shared by relay/DVM when needed. I think the common sentiment is that we all see usecases for private trust events, but implementation is more complex. We need interactive protocol for this - as Hodlbod mentioned - or ZK proofs, and who knows what. For now, I think we should go for public, discover the possibilities and implement private model when we know more about the problem / we see what the main usecases are.\n\n3. I would vote for an optional scalar \"score\" and \"confidence\" value. If they are absent, it's a binary true value.\n\n4. I like the \"context\" term. I think it could be optional, but see a lot of value in embedding into the event, so as it can be used by filters as input. I don't see clearly what is the usecase for it derived by filters. Is it like \"I trust this guy\", and the algorithm tells me the context it was used in?\n\n5. I'm probably not the one who has dig into it deeply. Not sure if this is what you mean by spec, but I'd like to know: what are the inputs/outputs, where the filter should be ran (client / relay / DVM / phone) and when (when content is created OR when queried). Should I be able to make a relay subscription based on a content filter?",
"sig": "63489f40be97ce7d913190bda4c22e6cd2148e94089281bc92a5738cd229a2c56b57af20a6e16e1ce4fecd7114f8752436205af9b8e552f454bf1230c7154cd8"
}