New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getting access to raw graph #17

Open
mmckegg opened this Issue Dec 1, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@mmckegg
Member

mmckegg commented Dec 1, 2018

I want to be able to get and observe the followers/following/blocking of people other than ssb.id (self). This can be done using the legacy stream function, but there doesn't seem to be a way to do this with the new api.

Any ideas? Or do we need to extend this?

Maybe a way to get the hopStream but with a particular reference point? But also in reverse too. Or expose the raw layered graph somehow (don't need it to work via rpc, local is fine!)

cc @dominictarr

@dominictarr

This comment has been minimized.

Member

dominictarr commented Dec 2, 2018

sure that sounds reasonable - can you give me some context on what you need this for?
yeah, it really ought to be possible to observe individual layers.
hmm, get is the legacy graph. It would definitely be better to provide access to the new internal model, so that the legacy model can be removed.

@mmckegg

This comment has been minimized.

Member

mmckegg commented Dec 3, 2018

can you give me some context on what you need this for?

This is mostly for the profile page in patchwork. When you view someone, you want to see who they follow, and who follows them, plus who blocks them.

With #18 merged, I am now using a combination of getHops({profileId, max: 1, reverse}) and manual filtering onEdge to generate a change stream.

But that is really just recreating hopStream with the ability to pass options as hops. How hard would it be to support that directly?

@dominictarr

This comment has been minimized.

Member

dominictarr commented Dec 4, 2018

isn't making this really real time kinda overkill? it's not like friends changes that quickly. why not just generate it from a request to friends.get (or something) and some tricks to make it seem more responsive - like, show the cached one, then rerequest and morphdom to update (just incase). Or cache and invalidate the cache and recalculate that page if someone follows them or they follow someone.

from my experiments, at least in patchless, the heaviest part of this view was just displaying hundreds of avatars. resizing them helped.

But that is really just recreating hopStream with the ability to pass options as hops. How hard would it be to support that directly?

If you really did want to make it real time, https://github.com/dominictarr/dynamic-dijkstra#traverserupdate-g-_g-hops-max-start-from-to-value--diff lets you update edges to a graph and get the diff to hops, including weird cases around removing edges. You might remember one time at art-hack when we discovered that just calculating the hops was the main block on initial sync! this one is really fast now, even to remove edges.

But I'd probably advise against tracking the real time friends for everyone, because that would be a lot of memory to track hops from every peers perspective.

@mmckegg

This comment has been minimized.

Member

mmckegg commented Dec 4, 2018

@dominictarr

why not just generate it from a request to friends.get

Isn't that deprecated?

But I'd probably advise against tracking the real time friends for everyone, because that would be a lot of memory to track hops from every peers perspective.

That's not what I'm proposing. I only want to track the hops of the currently open profile page (remember patchwork doesn't have tabs). And it's not really hops that I want to track, just every one that a particular individual follows and blocks in realtime.

I got it working just fine with a combination onEdge and hops in Patchwork, so there is no need to change anything in ssb-friends or layered-graph. However, if you think it can be optimised beyond my hack above (by direct support, as it's the reverse hops that are the tricky part), then I'd be interested.

Like I said, I only need a max depth of 1. This is really just the raw data coming off onEdge (filtered to a given feedID) but also in reverse. Feel free to close, if you don't want to optimise this further.

@dominictarr

This comment has been minimized.

Member

dominictarr commented Dec 4, 2018

well, really what I want right now is to understand how you are using it... also it just occured to me that by using hops to track this, it'll adapt to multidevice nicely. If it's only one set of hops being tracked at the time that's okay!

hmm, the way you are doing it now works fine for hops = 1 but you'll need to use dynamic-dijkstra for a hop distance greater than 1.

@dominictarr

This comment has been minimized.

Member

dominictarr commented Dec 4, 2018

oh, and also it gives you a stream that's like: initial hops: {<id>:hops,...} and then updates also also that format, you just merge them! would that be easier?

@mmckegg

This comment has been minimized.

Member

mmckegg commented Dec 4, 2018

hmm, the way you are doing it now works fine for hops = 1 but you'll need to use dynamic-dijkstra for a hop distance greater than 1.

Oh okay, so the option for passing max won't really work then? I don't really need that anyway.

oh, and also it gives you a stream that's like: initial hops: {:hops,...} and then updates also also that format, you just merge them! would that be easier?

Yes, that would be perfect!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment