Notices by silverpill (silverpill@mitra.social)

@adiz @icedquinn

Yes, we brought Zot features to ActivityPub. Streams now supports both Zot and ActivityPub nomadic identity. Forte, the next project in this chain of forks, is rumored to be ActivityPub-only.

@damon @david

@sendpaws @tadano Mitra can hide instance timeline (actually it should be hidden from guests by default unless I messed it up somehow).
Hiding users and posts is a good idea, I'll add that to my list

@helge I currently restrict them to public, but only because implementing private quotes is tricky.

@sendpaws

Thank you for writing this!
Moderation tools are slowly being added, with instance-level filters coming first. If you need a particular feature, please let me know, maybe I'll be able to add it quickly. Other comments:

- It can run on FreeBSD (there is at least one instance)
- As @tadano mentioned, full text search can be enabled by prefixing your search query with >.
- Could you tell me more about the "ability to hide timelines for logged-in users"? How it should work?

@b0y Mitra backend seems to support pre-hashed signatures, but the frontend asks for legacy ones. I probably wanted to wait until instances upgrade before using pre-hashed by default, but then forgot about it :)
Will fix this in the next release

@mikedev

>So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else

Shouldn't Create|Update|Delete also have activities in context?
My understanding is that context collection is supposed to contain things that have collection ID as their context property.

If entity is an activity, its context is a collection of activities.
If entity is a post, its context is a collection of posts.

@julian @pfefferle @jesseplusplus @trwnh @mario @harmonicarichard @reiver @aslakr @Fitik

@julian Yes, I tested against NodeBB and other implementations mentioned in FEP-f228. Will add WordPress and Frequency to the list

@julian @pfefferle @jesseplusplus @harmonicarichard @trwnh

>yes, but they serve objects because we're radical implementors who don't do the whole activities thing 😝 sorry in advance.

My server can retrieve both kinds of collections :) I had concerns about diverging / conflicting implementations in the past, but the solution was found...

>We were testing against these URLs from @pfefferle@mastodon.social's personal blog

This context is working 👍

>@jesseplusplus@mastodon.social had a test URL but NodeBB fell over because it encountered an Object in next instead of a URL

I have a problem with this one because the first page doesn't have an id. I can adjust my code but the absence of id is unusual. For example, there is a next page (currently 404), and if we navigate to it, how prev would look like if the first page is anonymous?

>All top level or mid-level objects should report a resolvable context

Do you mean replies made by the context owner specifically? I think remote mid-level replies should not be required to have context (that would prevent non-implementing servers from participating).

@julian @pfefferle @jesseplusplus @trwnh +1 for chronological order requirement.
Are those implementations public? I'd like to test my context resolver against them too

I just quoted it. What part of the collection definition you don't understand?

@helge @jenniferplusplus

I never understood what Mastodon is doing with followers-only replies. It's just nonsense.
I initially only allowed DM replies to followers-only posts, and recently switched to "conversation" visibility where replies inherit audience of parent post (idea stolen from Streams/Hubzilla).

I already provided several examples, but if that is not enough you can read the definition of Followers collection:

>Every actor SHOULD have a followers collection. This is a list of everyone who has sent a Follow activity for the actor, added as a side effect.

@trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal Application actor is recommended, which is not a "user".

The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.

@julian

We are talking about ActivityPub here. AS2 definition of Follow activity is irrelevant because followers/following collections and inboxes only exist in ActivityPub.

@scott

Yes, I'd like to subscribe to arbitrary threads. For example, I often subscribe to issues on Github/Codeberg, or watch selected topics on SocialHub.

Another reason is client to server ActivityPub. Even if we implement thread subscriptions in a non-federated way, clients still need to tell servers about subscriptions somehow.

@julian If these limitations don't prevent us from implementing any features, why they should be addressed?

The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.

@developer I do

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

Multi-typing is not necessary, it can be an Application without a second type, or an object with a non-standard type but duck-typed as actor.

Anyway, there is a bigger problem. This FEP doesn't explain what "following" means if Follow.object is not an actor. ActivityPub spec says that Follow is used to subscribe to actor's activities, but what follower is supposed to receive from an object? Objects don't perform activities.

Regarding topic subscriptions, I already talked about my preferred solution in another thread. Now there is a formal proposal: https://codeberg.org/fediverse/fep/src/branch/main/fep/f06f/fep-f06f.md

@i Pleroma instances have a relay actor, for example yours has https://declin.eu/relay. In theory its outbox can be used for backfilling , but it doesn't work (idk, maybe it can be enabled somehow?)

https://declin.eu/relay/outbox