ssb-friends shouldn't assume that all `contact` messages are about follows

[mmckegg]

Right now, if someone creates a contact without the following key, ssb-friends assumes that you have unfollowed that person.

ssb-friends doesn't check to see if the following or blocking fields actually exist, it just runs a falsy check on following. It should instead check to see if following or blocking is typeof 'boolean' first, and if not just ignore the message.

I am currently experimenting with implementing sameAs as a type: "contact" message so this is a bit of a problem.

cc @dominictarr

[dominictarr]

there will still be other people running old code that will have this behaviour, so I think it's simplest for sameAs to just be another type of message. That way it's safer to opt-in. That, or put the current follow state inside the sameAs message.

[mmckegg]

@dominictarr

so I think it's simplest for sameAs to just be another type of message

I'm open to this but, the reason I was keen to put merging into contact is that ssb-friends needs to know about sameAs for replication purposes (including friends of your other identities in the same hop distance). If it was a seperate type, we'd need a second index.

That, or put the current follow state inside the sameAs message.

I think we should do both: fix this and also put the follow state in the message.

Fixing is fully backwards compatible (apart from the potential confusing of these extra contact message types potentially interrupting some replication, but it will only be for people with old clients, and if the client hasn't added the follow state).

ssb is still a young project with very few clients in the wild, we can nip this in the bud! Unless you really feel strongly that contact messages should ONLY be about following.

[dominictarr]

I think we should do both: fix this and also put the follow state in the message.

Okay I agree with this - it will keep working for current implementations, and also make sense moving forwards.

hmm, if we change this behaviour - does a blocking message still make sense? it's normally {blocking: true} (implying an unfollow, doesn't this change mean it's implied still following, but also blocking?)

I don't think we have a clear story on exactly what contact messages do. One point in your favor: ssb-friends will need to understand sameAs, but if those look like follows, old instances will do basically the right thing anyway.

ssb is still a young project with very few clients in the wild, we can nip this in the bud!

it's not just the clients, it's people running old pubs etc. it should do something sensible on those. Dealing with updates like this is gonna be a big problem in the future, so we should practice thinking about how we approach it before it becomes a truely big deal

[mmckegg]

@dominictarr

it's not just the clients, it's people running old pubs etc. it should do something sensible on those. Dealing with updates like this is gonna be a big problem in the future, so we should practice thinking about how we approach it before it becomes a truely big deal

Yep, good point! The pubs are the biggest issue.

My main problem with putting following: true on the sameAs messages is actually a UX thing. I need to know how to render the contact message in the interface (is this a follow, or a merge, or a block). I suppose we'll just have to do it the hard way in the interface and do some kind of diffing of the old state 😩 or guess based on the keys. But this will make old clients render the message wrong.

Though, if a pub thinks that you unfollowed your identity, then this might be a big problem. Your other messages won't get to your friends, which is exactly the opposite of what we want.

Okay, who cares about the clients and them rendering the wrong info. Let's prioritise the pub replication!

I think I'll just make do with the nasty UX hacks, and put following in the contact messages (with a // HACK comment, but we should still fix this!

hmm, if we change this behaviour - does a blocking message still make sense? it's normally {blocking: true} (implying an unfollow, doesn't this change mean it's implied still following, but also blocking?)

A blocking state should override a following. However, I think if the user unblocks, they should probably go back to following again unless the explicitly added a following: false. That would be like an about message 'hide: true` would also hide someone's display picture, but if you unhid them, their display picture would show again.

ssb-friends will need to understand sameAs, but if those look like follows, old instances will do basically the right thing anyway.

Yep! This works great (well okay) at 3 hops, but at 2 hops, FoaF multi-identities will drop off. ssb-friends needs to drop down the hop distance to match the sameAs contact for these identities.

[dominictarr]

so if you block someone you follow, then unblock them, I think the state should be not following. I don't want to complicate the data model by remembering if this is a block while following vs block while not following. If that is shown in the UI, you can follow them again if you want. This is already the current behavior anyway.

[dominictarr]

thinking about how ssb-friends would represest sameAs... it's kinda like a super follow. follow, but don't increment their hop score. (this will be an easy interpretation to implement)

really, we should check that they are also sameAs back... hmm... is it a security problem if we don't do that? If someone you follow says they are sameAs someone they arn't, you'll end up replicating messages you didn't actually follow... hmm, oh dang - it would need to replicate the sameAs feed anyway, just to see the sameAs message

[mmckegg]

really, we should check that they are also sameAs back... hmm... is it a security problem if we don't do that? If someone you follow says they are sameAs someone they arn't, you'll end up replicating messages you didn't actually follow... hmm, oh dang - it would need to replicate the sameAs feed anyway, just to see the sameAs message

Fun! 👻 Interesting problem. My intuition is that this is fine, but... uh... I'm sure someone felt good about encoding years as 2 digits in the Y2K bug too.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.