requesting advice for implementing a PR: ooo messages

[dominictarr]

I was gonna make a PR to implement support for out of order messages, basically all the needs to happen is when feed.obs.thread sees a branch to a message it doesn't have it uses sbot.get (since with ssb-ooo this can retrive those messages by gossip requests)

but a few problems: feed.obs.thread is implemented in terms of backlinks.obs ... I'd rather have a stream here... I only want to check each message once, so I could add a thing that checks wether I've already checked it as it comes out of backlinks (basically making it back into a stream) but that is ugly...

I also implemented it here, in the module that patchsix uses: https://github.com/dominictarr/ssb-thread/blob/master/index.js but I want to drop it right into patchcore apps, so just using that isn't ideal...

I would just rewrite thread in terms of sbot.pull.backlinks but then there is this caching stuff that seems important in backlinks.obs.for

any recommendations?

[mmckegg]

@dominictarr

feed.obs.thread is a big mess! Me and @mixmix have been meaning to talk about that for ages.

In patchwork, I handle missing messages by doing an async lookup and then appending a DOM element directly above if missing. Maybe this could be replaced with the OOO version?

But as for directly in patchcore, not sure yet. Maybe it could be snuck into backlinks.obs?

Actually, I think that if we can somehow tell sbot to request the OOO, it will end up in backlinks.obs all by itself. What's a good mechanism for requesting these messages? What about a plugin that sits in sbot and watches every gossiped message and then requests any missing messages via OOO? Then you wouldn't have to make any changes at all to patchcore.

The good thing about that option is OOOs would appear in the main feed rollup too (not just in the thread).

[dominictarr]

let me clarify some things about how ssb-ooo works: ooo messages are requested by a flooding gossip request - you send a message to any peer that "I want X message" then they send it to you or ask their peers (up to N=3 hops away max) when you receive that message, it's stored in a separate log which contains only ooo messages. This means that ooo messages do not appear in the other ssb indexes. This is because it would massively complicate message validation and you get to be sure that indexes are actually in order by feed.

Also, you might not want to get all the ooo messages, so they are only pulled in when the application requests them at display time (like blobs)...

---

question: main feed rollup? you mean that the main feed rollup doesn't use feed.obs.thread?

[dominictarr]

I don't want to pull in every possible ooo message... that wouldn't be efficient. I'd rather the applications in use decides which are needed. (thinking forward to when there are many applications)

[mmckegg]

Ah okay, thanks for the clarification. Skipping indexes makes sense.

Yeah, the main feed doesn't use feed.obs.thread (that's only when you view a message directly). It uses a combination of a custom index and feed.obs.withReplies. There's also feed.obs.rollup which is used on the other views like mentions, profile, channels and private.

OOO potentially could be added to withReplies as well as thread. However in patchwork (though can't speak for patchbay), I think this would be best handled by modules/message/html/missing.js

Does sbot.get with an OOO give you any kind of indication that the message came via OOO instead of the normal route?

[dominictarr]

handling it in missing would work... but mind you, there could be recursively more missing messages... it does make sense to put a place holder for the missing message in there though, that gets populated by ooo. then you could show some sort of progress indicator for it (at least, wether or not you've broadcast a request for it...)

just that it has ooo: true on it... I'm fairly sure that patchbay@7 just uses feed.obs.thread... although for the /inbox view it might not. @mixmix ?

[mixmix]

Can't remember, I think i used feed.pull.rollup for main view in patch-inbox... Feel free to break things, I need to rework inbox with mutant-scroll anyway

On Sat, 9 Dec 2017, 12:57 Dominic Tarr, notifications@github.com wrote:

handling it in missing would work... but mind you, there could be recursively more missing messages... it does make sense to put a place holder for the missing message in there though, that gets populated by ooo. then you could show some sort of progress indicator for it (at least, wether or not you've broadcast a request for it...)

just that it has ooo: true on it... I'm fairly sure that patchbay@7 just uses feed.obs.thread... although for the /inbox view it might not. @mixmix https://github.com/mixmix ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ssbc/patchcore/issues/48#issuecomment-350402220, or mute the thread https://github.com/notifications/unsubscribe-auth/ACitnvGoDmQdFQbs10dKI67VjmAq0ofpks5s-cz_gaJpZM4Q7mxc .

[mmckegg]

@dominictarr

Is any of the work on ooo public yet? Can I start experimenting with this?

By the way, I just added message.obs.get, an observable that returns a message once resolved. I'm thinking that this could be extended to support OOO (and also watching in case a message does get synced eventually). This is now being used by missing message in patchwork.

[dominictarr]

@mmckegg yes if you use patchless or patchsix and are running ssb-ooo then it works already. ssb-ooo ssb-thread just calls get on missing messages which triggers ooo.get

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