#Smithereen 0.11 is out!
-
#Smithereen 0.11 is out!
This one mostly focuses on groups and moderation. Groups now have discussion boards, admins can specify server rules (with translations!), moderators have more and better tools at their disposal, and users can now pin posts and export their data.
Detailed changelog here: https://github.com/grishka/Smithereen/releases/tag/0.11
Now comes the part where I build the client API I promised everyone for so long. And the website.
-
#Smithereen 0.11 is out!
This one mostly focuses on groups and moderation. Groups now have discussion boards, admins can specify server rules (with translations!), moderators have more and better tools at their disposal, and users can now pin posts and export their data.
Detailed changelog here: https://github.com/grishka/Smithereen/releases/tag/0.11
Now comes the part where I build the client API I promised everyone for so long. And the website.
grishka@mastodon.social would you be interested in implementing conversational contexts/backfill (aka 7888 + f228)?
-
@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
-
@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
grishka@mastodon.social this would be in addition to replies collection fetching
You'd poll one endpoints to get all of the replies in the tree. Mastodon will support serving this collection soon!
-
@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
