this is a duplicate of ssb-friends

[dominictarr]

ssb-friends does the same thing and is already built in. why not just use ssb-friends instead? I'd be far happier to merge a PR into ssb-friends than to run another index that does basically the same thing.

[dominictarr]

and on that note, it's better if map contains a minimum of redundancy, because it's probably gonna be streamed to a client. ssb-friends uses {from, to, value}

[mmckegg]

If it was{from, to, value, scope, timestamp} I could use ssb-friends instead.

[dominictarr]

what do you use scope and timestamp for?

[mmckegg]

I am not using them yet, but have big plans for them!

I need the timestamp for implementing sameAs merging, to know which feed has set a value more recently.

scope will be used to allow parts of the graph to not be replicated by certain peers (apps), and to hide certain types of follows from the interface.

[dominictarr]

sameAs meaning multidevice? can you describe how the timestamp is used for that?

[mmckegg]

My idea for implementing multi-device is to use sameAs "about" messages where you point to the feed you want to merge into the target: %uB7DTsgCgOgH46vKrlzNQTP0DuLcIzIVOXy0ukIWwaE=.sha256

Feeds would count as merged if targeted by a sameAs message where the author is sbot.id, or if feed authors have sameAs messages pointing at each other (by directional sameAs).

I was thinking of implementing this at the patchcore level. This would mean that calls to observables like about and contact with a feed's key would give you the reduced state of all the feeds that were merged into this.

Patchcore wouldn't know which value should win in the reduce unless it had access to the timestamp of the most recent change.

[dominictarr]

I think we should be careful about memory usage, and this is a 5.9 mb json file, (vs ssb-friends's 1.8 mb) and in patchbay@7, it produces by far the largest in memory object, at 9mb retained size. I don't think there is any need to use this much memory, and better perf is better user experience.

One thing that might be a better strategy is to move index the sameAs data separately.

[mmckegg]

@dominictarr

I think we should be careful about memory usage, and this is a 5.9 mb json file, (vs ssb-friends's 1.8 mb) and in patchbay@7, it produces by far the largest in memory object, at 9mb retained size. I don't think there is any need to use this much memory

Yeah I completely agree.

The main reason it is so much bigger is because it indexes both directions, which is completely unnecessary. With some small changes, it would be half the size. I didn't know what I was doing with flumeview-reduce when I made this! 😆

One thing that might be a better strategy is to move index the sameAs data separately.

The reason sameAs needs access to those timestamps is otherwise we don't know whether a merged feed most recently followed or unfollowed someone. Do you have any ideas about how we can store this more efficiently? It needs to be fast!

Same with scope, how do we quickly figure out (at gossip time) which FOAFs we actually want to ask about if we don't have a reduced scope state?

cc @clehner

[mmckegg]

From %jM6Dw0BEg9IPVkDH5VaoiVSbt3gCnUfSoO1BhX2Ntpw=.sha256

what if it was following: scope and boolean means "everything" maybe it could also be an array if you follow them in multiple scopes? or an {} object.

I'm mainly interested in keeping the follow graph datastructure as elegant as is feasible.

nice!

[dominictarr]

hmm, so after sleeping on this, I think there are a few approaches, all with advantages and disadvantages

for the following, suppose we already have a black box that tells us when two feeds are sameAs each other.

timestamp per action

combine both feeds in the index, last writer (on claimed time) wins. this is pretty simple, but downsides: sometimes some people get their clock out by like hours (it's a windows thing, i think) that would make this not work (never trust a timestamp)

hash pointers for actions that supercede another

a update to a state also has a branch link to the previous states, as with threads, etc. This is nice because you know exactly the order. it's explicit. but it would mean you'd need to track those links, further bloating the indexes, and you'd need to do IO while generating the view. That is not impossible in our architecture, but it would increase complexity significantly.

just track each feed's follows individually

just do nothing - if you follow someone from laptop and block from phone, stop replicating them on laptop, and show a prompt if they would like to also block them on the laptop (i.e. fix in the UI) allow cases where you are following on one device and not another. example, if you follow on laptop, block on phone, then replicate on laptop. If you are foaf on laptop, block on phone, then do not replicate on laptop (since you didn't explicitly follow)

I think this is by far the simplest, and also doesn't need timestamps, and I think there are legitimate use cases, like maybe you want to block someone from your work computer, because they are too distracting (or vise versa, block your boss from your home ;)

On http social networks, you are just an account id, and you are the same person whether you are using keyboard or touchscreen, in ssb necessarily you are two different identities - but maybe that is fitting. I would not have written this long a response tapping on a phone screen, how you perform yourself on different devices is very valuable context, maybe they shouldn't be mashed together too much?

---

I was also wondering how you'd integrate this with the index of sameAs links, but then I guessed it: you'd just make a separate index of sameAs, and then merge the follows graph for the two feeds at query time, right? that way you don't trip up on follow state interacting with sameAs state (as your devices "marry" and are "divorced")

[mmckegg]

@dominictarr

just track each feed's follows individually

Hmm, yeah. I think we should be able to make some variant on this work well.

It's easy to resolve if only one of the feeds has a contact message about someone (or they are all the same). It only gets complicated when one feed has {following: false} or a different following scope, or a block. If there is a conflict (and we need this info), we can then fall back to some sort of query to find out which one should win.

As for the the timestamp thing, this is up to the user to make sure their different machines are in sync, maybe we could warn if a user tries to post to a feed sameAs another when that other feed has more recent timestamps.

A thing to keep in mind with all of this is we don't just need sameAs for ourselves (own feed), we need to be able to do it for everyone. This is mostly so we can know who to replicate and who follows who when looking at a profile. I suppose the second case (profile) doesn't have to be fast, and maybe the first (replicate) can be hacked around. Maybe you follow your own identities? That way foaf can handle this. And not worry about merging together other people's feeds at this level (blocks won't be quite as effective, but that's about all I can think of).

Thinking at keyboard here! 🤔 But yes, I like where this is going. 😌 In this case, we can probably ditch this module ssb-contacts. I will look at ssb-friends and see what I need to change in patchcore or PR to make this work!

[dominictarr]

thinking at the keyboard is a great place to think! TATK!!!

[mixmix]

patchcore is now rolled with ssb-friends. I think this is resolved now

[mmckegg]

FOR NOW! That is until we want to implement sameAs. 😱 😆

Apparently we figured out how to do it above. It'll probably be fine.

[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.