@nelson@wetdry.world given the architecture i'm proposing is effectively the atproto PDS/AppView split, i don't think there's too much that's activitypub-specific here
Post
Replies:
9
> separate data hosting from data interpretation
https://activitypub.mushroomlabs.com/topics/reference_context_architecture/
> with many objects and slow connections the overhead of creating new http requests would add up significantly
GraphQL and/or SPARQL
> iterating through my inbox every time i open my “home timeline”
The same your email client works: sync the inbox, create index view in the clients. That's at least what I am doing for my C2S client. My problem now is that I wish that C2S had a way to say "clear my inbox"
@raphael@communick.com
> GraphQL and/or SPARQL
these can be valid options but they add complexity to the C2S server, which is both the part that individual users would want to self-host AND also the part already burdened by having to deal with the traffic bursts caused by things like boosts and replies by large accounts. i think if a query endpoint were to be created it should be maintained by a client (at least architecturally, if an implementation wants to merge them both it's their choice!)
> The same your email client works: sync the inbox, create index view in the clients.
this still does not address the problem. an actor's inbox contains way more than just the Posts on their Timelines (and will do even more if AP were to be the Everything Protocol it dreams on being). you'd need to load pages upon pages of as:Like, litepub:EmojiReact (and as:Undo for both), as:Listen (e.g. following someone using pleroma scrobbles), various as:Add as:Remove as:Update as:Delete "management" activities for unknown objects, and so on which will swiftly get thrown away but still end up consuming latency (especially after a few days of being away) and often-costly mobile bandwidth
email clients work because your inbox Only contains Emails. the data you get is pretty much all relevant, you don't end up discarding huge chunks of it
@raphael@communick.com i also have personal opinions around graphql/sparql such as the ability for a client to create slow and resource-consuming queries and concerns around how a shared C2S server is supposed to rate limit those, but given graphql's popularity these already have some discussion and acceptable solutions, though we really don't need facebook-scale tooling for this
This is what I am planning to do to deal with huge inboxes: https://codeberg.org/mushroomlabs/django-activitypub-toolkit/issues/31
As for SPARQL/GraphQL: yes, if I am syncing all the data (that I want) to my local database, I'd implement the query engine *in the local client*.
And I am not even thinking about discarding anything. JSON can compress nicely, so I'd keep an actual database for the indexing and JSON-LD documents as a local archive.
@kopper nah it's good shit. i've been meaning to compile all my thoughts on the subject but you basically did it for me with this piece 👍
@kopper unfortunately not the point but this is easily the craziest css i've ever seen. bravo
@kopper should i read this if i'm not working with AP
i was considering whether i should just do c2s versia
@nelson@wetdry.world given the architecture i'm proposing is effectively the atproto PDS/AppView split, i don't think there's too much that's activitypub-specific here
This is marvelous. I wasn't aware of your project, but now I am and added it to the #ActivityPub #C2S tracking list.
I've also lined up #Outpost for inclusion on the delightful #fediverse curated lists at https://delightful.coding.social
