@obenland@mastodon.social wonderful, good work!

@AltCode all three flipboard remote categories seem to be working now

@AltCode One significant potential issues with listing all followed categories in the same kind of layout as /categories is the below-the-fold effect, or the page-2 effect as one might have called it in earlier times. Whatever categories end up falling below a certain scroll distance will just never been seen by most users. If you follow a lot of categories, the ones that end up closer to the bottom of the list than the top will just end up ignored. It doesn't encourage participation, and it also doesn't discourage following a lot of categories that you don't actually care about. And follow relationships are very important under ActivityPub, since they dictate content flow. Bringing in a lot of remote content that no one on the local forum is actually reading or engaging with is very wasteful. An easily accessible compact list might be better, with different sorting options so that users can choose to have categories with new content float to the top. Usually with forum categories, you want the ordering to be static, but that expectation won't necessarily be there for just a list.

I asked in that issue whether Lemmy finds community via to/cc (it does). Does PieFed do the same? Yes - PieFed does the same. It looks in 'audience', then 'cc', then 'to'. It has to, to support all the platforms that haven't adopted 'audience. It's a convenient field, but PieFed won't be affected if Lemmy goes through with removing it. Would this also open up the possibility of a topic/context being part of multiple audiences/communities? Not at present. If you do something like cc: [community1, community2] it will only go to community1 (on both Lemmy and PieFed). There's so many activities that are effectively duplicates, both in normal operation and when platforms are bugged (both Lemmy and Mastodon have gone through phases of sending the same activity multiple times), that you need a way to make sure you're only processing one. On PieFed, this is done by having a UNIQUE constraint of the 'ap_id' column of the Post table (the ap_id of your post is https://community.nodebb.org/post/103806), so it means you can't have the same post in more than one community.

@hamishcampbell @ricmac @evanprodromou @julian Thanks for your kind words. I won't interrupt your discussion with Julian anymore. I hope you reach some accord!

@johnonolan@mastodon.xyz no worries, and thanks! Will do.

I would honestly have been worried if the main people behind the protocol were busy trying to gatekeeep it.

That sounds good

@shoppingtonz@mastodon.social if edits from PieFed aren't reflected here that may be a bug.

1. +1. I will replace webfinger address recommendation with a warning about possible compatibility issues.2. I think observers (and other Application actors on the server) should use a shared key.

Really great talk! I think he did a really good job of introducing the concept of Solid with ActivityPub together, and why this combination would be desirable for people. Super excited to see the future of this project, I would love to see frontends from popular Fediverse servers ported over to ActivityPods app architecture.

> Doesn't this mean Mastodon users et al will no longer get boost notifications when their posts are reshared into a topic? Correct, only OP will be shared. Unless I am mistaken this is how Lemmy implemented it. Announce-ing activities only, and one single Announce(Note) for compatibility with Mastodon.

I recognize that this makes the Delete activity work differently for S2S than it does C2S, which is to say that a user or client cannot distinguish between "soft delete" and "hard delete" this way. Otherwise, the "cache invalidation" idea is a sensible one.