How are missing messages handled (e.g. when blocking someone)

Powersource commented 4 years ago

Discussion started here %9RB10KNjsBF1OfnNtHJ05t/4Iwe9O6y0CKyMkAamMik=.sha256

E.g. what happens when I call getHeads and how is it recommended I handle that. Since some messages will again look like heads for me but not for others, if I've blocked the author of the child of a message (the message that might now look like a head).

cinnamon-bun commented 4 years ago

Besides blocking, some participants will often be outside your social radius, so it seems like missing messages will be common.

E.g. a conversation between feeds A and B:

A0 <--B1 <--A2 <--B3 <--A3

If B's feed is missing, this falls apart into a bunch of individual heads from A.

These changes would add robustness but are not complete solutions:

Give each message a single additional backlink to that author's prior message in the tangle
Give each message 3 or 4 backlinks pointing further back in the tangle

mixmix commented 4 years ago

blocking is a hard case. ssb-tangle doesn't know about blocking, it only knows about what set of messages you pass it for reducing.

The choices I've made assume that if you want to be collaborating with someone and trust them then you have all their messages. If you don't them you won't be able to build tangle they've validly participated to - or rather you'll end up with multiple heads.

In particular, what ssb-tangle does is "walk the graph" of the tangle. It starts at the top and before it takes each step (to a message which declares it proceeded from a given message), it asks "is this next message valid. Any message which is not "connected" in a continuous way cannot be validated (this is particularly true when you start adding authorship), so any disconnected message and any message which builds from there I have chosen to ignore. It is possible to make a different decision here but honestly, thing get a lot more complicated if you let anything in (or rather it's a tradeoff with other affordances which become hard to guarentee which I care more about).

Message validity is something not tested for in ssb-tangles at the moment, but I've explored that functionality and plan to add it. see : https://github.com/ssbc/ssb-tangle/pull/1

mixmix commented 4 years ago

so concretely, if you have blocked someone and so aren't replicate someone and so you don't have edits they've made.... you just won't see those.

If others see those edits as valid and extend on them, then you won't integrate those because they extend from messages you don't t. If you're the only one who blocks that person, then your edits will be locked at the last change before that author posted (unless you extend the edits yourself).

important to note what "blocking" means. generally it means declare blocking: true and what ever does replicating in ssb then doesn't ask for updates on that person. Certain bits of UI will also exlude existing messages you have from that person. Already you can see "blocking" is a little grey as a concept. I don't like the idea but one possibility is to continue replicating them, but only make blocking in the UI... ech. I honestly think if you're blocking someone you don't need or want their edits. And if you had past collaborations maybe you should be forking off anyway.

mixmix commented 4 years ago

hmmm ... probably we should edit blocks so they declare which feed you're blocking AND from which message. That we you could say "we were chill until feed_blocked_person got to message 415, after then I didn't want to have any more of their edits / messages. Please keep ones before then though

Powersource commented 4 years ago

so yeah I think it's pretty fine to assume that collaborators mostly trust each other, but not forever, and maybe your friend alice who is e.g. reading the wiki doesn't trust your collaborator bob who you in turn trust. in other words, don't assume tangle holes by default, but it's not an unlikely edgecase.

one thing I'm thinking about (brainstorm level) is maybe some sort of bandaid type of tangle message/field, which would sort of be like the previous field but the module wouldn't yell at you for having it point at really old messages.

like, if you find a tangle with holes in it, your client would ask you "hey this tangle looks broken, here's a list of messages that might be heads or might be false heads, click the ones that you think are false and I'll hide them for you" and then the client publishes a message with

tangles: {
  boop: {
    root: 'a',
    previous: [...],
    bandaid: [false heads here]
}}

this would also kind of but not totally introduce multiple roots which I read somewhere that you were unsure about how you felt about.

another thing could be that when deleting messages we only delete the body/text of it, keeping the tangles. would turn into a protocol level change in that case I think, similar to gabbygrove but more fine-grained sort of (thoughts @cryptix if you have the energy to dive in here? :P ). this wouldn't help if you blocked the person because you thought they were making bad tangle stuff, but maybe the tangle validation would catch enough of those bad cases that that wouldn't be that big of a problem?

ssbc / ssb-tangle

How are missing messages handled (e.g. when blocking someone) #8