For social graph computations, is there a significant difference between doing it with Lists vs Relationship Status?
https://github.com/vitorpamplona/nips/blob/relationship-status/81.md
nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9
# 👀☕🇧🇷GM
Yes. Even when analyzing graphs, how you analyze them and how you build up the matrices of weights makes a huge difference.
Imagine you want to find out who the most influential person in a company is. It's basically a bunch of people and a bunch of connections. If you use a naive approach the algo might spit out the secretary, because everyone is connected to her and the boss has only very few connections.
We are in a similar situation when you want to compute what accounts are trustworthy.
Totally agree. Hence why I'm so stoked about #communikeys and Community Admins as high signal nodes in the graph. A follow from an npub that manages (takes on responsibility for) a community > a random follow.
My question above is more about what's the most efficient method to do "follows" in the first place.
A) Use Lists (that apps can mess up every time they want to add/remove someone + I'm guessing are not so easy to parse)
B) Use individual Relationship Status events (of which "follow" is just one type + which offer tons more flexibility and optional privacy)
lists seem to be failing us for many reasons, im all for trying the individual events, maybe that's better
Me too. And communities offer a kinda clean slate for fixing the obvious mistakes made in the pUbLiC sQuArE sphere.
But it's still intimidating (sunk cost, momentum and all), so I'd prefer to have a long list of solid arguments / advantages.
ive got some lists.. of the adv/disadv of lists.. 😁 maybe i could write them down.. 🤔
For me, this is the simplest rule:
How would you remove an event from a label collection? Delete the label event?
Only if that removes all labels from the event, yes.
If not, you just remove "follow" and leave "bitcoiner" (+ other labels) in there.
That's how I read the NIP at least.
trying to delete/modify and events getting spread far and wide past the relays theyre supposed to be on.. are part of why both solutions struggle..
imagine a scenario, if you're using delete to unfollow, that wont work. i could have you refollow me just by republishing the label you created.
(see how it gets weird?)
Wait, why can't we just look at the Profile's relay as the authority?
This is a more general "Delete" + "What Is The Latest Version?" problem and is imo fixed by just looking at the authoritative relay.
For Communities → main relay
For Individual Profiles → main relay
as long as you know what relay to look at yes, but the state of relay lists is pretty bad rn.. (stale, invalid, spread too far, etc)
for a community, yeah thats more of an authority than a relay list can be since its tied closer with the communities relays as the source.
Lol, yeah agreed on the state of affairs.
That's just because there's no daily driver apps that let you manage your relay in the app. Yet.
Graphs are not used to understand the market, they are used to create a narrative. Just draw the lines and patterns that you want to see and get everyone else to believe you're right.
This is the first time I see nip81, and it seems to me you can mimic lists with it.
The set of pubkeys in the "d" tags of nip81 "follow" is like your follow-list. So if everyone's nip81 follows are identical to their follow-list, then the result is the same.
However, why having a gazillion events where you can have just one per pubkey? Validating 1000 signatures per user is not a small feat.
it is a CRDT, it's supposed to be done once and cached
i'm glad to hear about this, i've also been saying this one for some time that mute and follow lists should be CRDTs - ie, add, remove, so long as timestamps are monotonic there is no confusion
what's hard about it is this: lazy programmers who don't want to build caches
I get the benefits of CRDTs, but it can create problems when some event in the change of diffs is not to be found. How would you deal with that case?
consistency is a fun game
a query where you can poll other nodes for "list kind but not these" would let you fill the gaps
it also hints towards the notion that users should have some "authoritative" store for their events (or stores) and at some point you have to throw your hands up in the air and say "the real world is a messy place" and too bad, so sad, get a helmet, to use some expressions that were popular in australia when i was a kid
the thing is CRDTs are *something* where the whole list is not just expensive bandwidth but also what if you can't find it, then it's all or nothing
Although I understand the data saving of CRDTs, I think they can introduce a lot of pain points, so I have a slight preference for the current grok brain approach of big lists.
yeah, big list is probably suited to gratis to store spam ridden relays, the signs are all there about what kind of security model was in the minds in addition to their expectations of their peers
