#Smithereen 0.11 is out!
-
@julian do you mean fetching the `replies` collections to make threads as complete as possible? I've been doing that for a long time already
Never seen those FEPs, will take a look
-
evan@cosocial.ca I think it's time to start drafting a SWICG report on backfill approaches hmm
-
@evan @julian yeah, that makes sense. Though implementing FEP-f228 as specified would be complicated for me because I don't store AP objects as-is — I treat ActivityPub like an API, so to return chronologically ordered replies mixed with likes, I would have to make database queries that would get very inefficient very fast (something like SELECT ... FROM wall_posts ... UNION SELECT ... FROM likes ... ORDER BY time ASC LIMIT x OFFSET y).
-
@evan @julian yeah, that makes sense. Though implementing FEP-f228 as specified would be complicated for me because I don't store AP objects as-is — I treat ActivityPub like an API, so to return chronologically ordered replies mixed with likes, I would have to make database queries that would get very inefficient very fast (something like SELECT ... FROM wall_posts ... UNION SELECT ... FROM likes ... ORDER BY time ASC LIMIT x OFFSET y).
grishka@mastodon.social most implementations just return the object IDs. Sending the entire activity stream is more difficult, although some do do it (e.g. silverpill@mitra.social's Mitra)
So "collection of posts".
-
@evan @julian yeah, that makes sense. Though implementing FEP-f228 as specified would be complicated for me because I don't store AP objects as-is — I treat ActivityPub like an API, so to return chronologically ordered replies mixed with likes, I would have to make database queries that would get very inefficient very fast (something like SELECT ... FROM wall_posts ... UNION SELECT ... FROM likes ... ORDER BY time ASC LIMIT x OFFSET y).
@evan @julian I solve the problem of running into a deleted replies by never fully deleting replies that have replies, instead clearing most of the data. So, for such a reply, I return a Tombstone that still allows the traversal of the thread.
I agree that this is still not optimal though. Running into a reply from a server that no longer operates would still break things. And you still have to make tons of requests (although Java's virtual threads make that reasonably fast).
-
@julian @silverpill that I can do fairly trivially
-
@julian @silverpill that I can do fairly trivially
grishka@mastodon.social yes, you and I don't store all ActivityPub objects, and neither does Mastodon. That's why attempting to serve activities is a non-starter.
Mastodon will serve the object IDs.
Lemmy (not released yet) and Piefed (v1.2) also implement this collection, so having another implementor be able to use them would be great.
-
@julian I have this convention where I return IDs for remote objects (obviously, how else would you authenticate them if not by fetching from the origin servers) but complete objects that are local, to save resources. IIRC I saw Mastodon do it for replies so just copied this behavior
-
@julian I have this convention where I return IDs for remote objects (obviously, how else would you authenticate them if not by fetching from the origin servers) but complete objects that are local, to save resources. IIRC I saw Mastodon do it for replies so just copied this behavior
grishka@mastodon.social that's a really interesting question, and I put those thoughts in a new topic
Returning objects in a collection vs. IDs
In another topic (#Smithereen 0.11 is out!), @grishka@mastodon.social says this: I have this convention where I return IDs for remote objects (obviously, ho...
⁂ ActivityPub.Space (activitypub.space)
-
@julian doooooo iiiiiiit
