Email or username:

Password:

Forgot your password?
jonny (good kind)'s posts Post Back to profile
Top-level
Emelia 👸🏻

@jonny you'd probably want to push them across to the streaming server for that to happen

19 September at 4:29 | Wall-to-wall | Open on hachyderm.io
10 comments
jonny (good kind)

@thisismissem one of the major parts of the program i have yet to explore. i'll take a look, but from cursory glance it doesn't seem too hard :) taking a break for some food now and then will continue on that.

19 September at 4:30 | Open on neuromatch.social
Emelia 👸🏻

@jonny that or just return a header when the replies collection is out of date & refresh (poll) regularly.

19 September at 4:49 | Open on hachyderm.io
aburka 🫣

@thisismissem @jonny streaming seems better because then other frontends would get them too?

19 September at 4:56 | Open on hachyderm.io
jonny (good kind)

@thisismissem is there a method you would prefer? I am not seeing a streaming endpoint for any generic DetailedStatus feed, maybe the Direct feed is closest? if polling would be preferable to adding a new stream/adapting another feed then i could figure that out, i'm just never sure what the most efficient way to do things with redux is

19 September at 4:59 | Open on neuromatch.social
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 | Open on social.treehouse.systems
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
Emelia 👸🏻

@jonny well yeah, there's no functionality in streaming for updates to replies on a single status so both approaches are about as "good" — iirc your intention isn't to upstream this?

19 September at 9:19 | Open on hachyderm.io
Go Up