Email or username:

Password:

Forgot your password?
jonny (good kind)'s posts Post Back to profile
Top-level
kouhai, resolver of merges

@jonny @thisismissem some of this feels like “it depends”. polling will be chattier, especially without connection reuse via H2/etc. websockets will make state management after disconnect a minor issue complexity wise

note that depending on implementation, polling may also incur the expense of a round trip vs half trip

19 September at 5:30 | Wall-to-wall | Open on social.treehouse.systems
4 comments
jonny (good kind)

@kouhai
@thisismissem
I am thinking it might be nice to just make a streaming endpoint for when one is in a thread both for this and in general. On a given instance, the thread ancestors are always known (I think?) From the threadresolveservice, or at least wouldnt mutate in the client (?). A new status can similarly always resolve its thread root on the server. So if there was a streaming feed for every root post, that might be a reasonably efficient way to do it, so eg. Multiple viewers with different points in a broad and deep thread could all sub to the same feed, and every new post has exactly one feed it would need to be added to.

Since the context endpoint is unpaginated and you always get the full parent tree when you mount a thread view from any point in a thread, I think you could mount and unmount the stream w/relatively low complexity in the client? Gonna give it a shot

@kouhai
@thisismissem
I am thinking it might be nice to just make a streaming endpoint for when one is in a thread both for this and in general. On a given instance, the thread ancestors are always known (I think?) From the threadresolveservice, or at least wouldnt mutate in the client (?). A new status can similarly always resolve its thread root on the server. So if there was a streaming feed for every root post, that might be a reasonably efficient way to do it, so eg. Multiple viewers with different...

19 September at 5:38 | Open on neuromatch.social
kouhai, resolver of merges

@jonny @thisismissem threads can’t always be resolved to a global concrete root. For example, you might have been tagged into a private thread that is otherwise entirely on another instance. This is also not necessarily immutable. For example, you might run into the above case with followers only visibility.

So, in this case, it might not actually matter, so long as you actually dedupe on the fly. That might not actually be necessary at all, but doing so could be an optimization.

19 September at 5:46 | Open on social.treehouse.systems
jonny (good kind)

@kouhai
@thisismissem
Right right, I meant global to an instance, like an instance will always have the same notion of root across accounts and client/server. Maybe there's a privacy argument to be made if eg. The OP has blocked someone downthread, but I dont see a huge harm scenario in someone merely knowing about a handle being the OP if they inspect their network traffic.

I guess since the current methods need to traverse and give you all the ancestors anyway, the redis publish call could check for the existence of any subscriptions to parents?

@kouhai
@thisismissem
Right right, I meant global to an instance, like an instance will always have the same notion of root across accounts and client/server. Maybe there's a privacy argument to be made if eg. The OP has blocked someone downthread, but I dont see a huge harm scenario in someone merely knowing about a handle being the OP if they inspect their network traffic.

19 September at 5:54 | Open on neuromatch.social
kouhai, resolver of merges

@jonny @thisismissem i think im too tired at past-midnight to do system design lollll

19 September at 6:18 | Open on social.treehouse.systems
Go Up