Notices by silverpill (silverpill@mitra.social)

@apps ActivityPub's Follow activity is intended to be used on actors: https://www.w3.org/TR/activitypub/#follow-activity-outbox.

This is one of the reasons I proposed that "observer" actor. Another option is to use a custom activity (e.g. Watch).

@liaizon Domain names are NFTs rented from ICANN

@apps I wrote this FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/f06f/fep-f06f.md

Object observer is an ActivityPub actor that can be followed to receive object updates.

However, I never implemented it. Pulling context and replies is often enough.

@sabrinkmann Why create different versions when you can use one?

There are ways in which the Fediverse can accomodate the greater number of different services:

- Content negotiation: every server advertises supported types, and the sender needs to adjust activities depending on what the recipient understands.
- Duck typing: recipients don't filter received objects by type, and instead look at their properties.

I don't think the first approach can work at scale. It's like serving different websites to different web browsers.

(Negotiation can be useful in some cases, though - I even wrote a FEP about this: https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md)

@Profpatsch @grindhold

@mike I still have no idea what your problem is. In the worst case, other implementations will not be able to backfill your conversations, that's all. It's not the end of the world.

FEP-5219: Groups and permissions has been added to the FEP repository.

#fep #fep_5219

RE: https://mitra.social/objects/019e87e9-62a6-71d1-8edc-3a8a63e96c9f

@jupiter_rowland

Forte has quite a bunch of private, single-user servers, but to my best knowledge, there's only one with open registrations.

Could you share it? I am looking for an instance where I can do federation tests.

@sendpaws @phnt

That's the plan. I am trying to introduce new features (such as fine-grained permissions) while keeping it as close to existing implementations as possible.

@nutomic @rimu

I am working a FEP which in some ways is related to your proposal:

FEP-5219: Groups and permissions

It introduces a new collection called affiliations, which is intended as a single source of information on who is allowed to do what (within a specific domain).

The FEP is mainly concerned with FEP-1b12 groups, but the affiliations collection could also be attached to Application actors, and be used in a way you described in FEP-baf5: Administrator Collection

@phnt Nicolium?

@mike

About the 403 - was it fetched by your site actor perchance? They aren't one of my followers. I'm not seeing any permission issues currently, though I'll keep investigating.

No, I am making a request on behalf of my personal actor. Made another attempt at 2026-06-11T10:03:56Z with the same result.

Let's just remove this line from FEP-171b. Then I think I can make most everything else work.

OK, I will remove it.

@phnt Lol. Maybe it will be included in ActivityPub 1.1 at some point around the year 2040.

@trwnh It's a long story, but the gist is that there are major architectural differences between @mike 's implementations and many others. contextHistory was introduced in an attempt to create a conversation backfilling algorithm that works with all implementations

@phnt I only implemented C2S Likes so far. What's the deal with Announces?

The biggest problem with C2S is that objects and activities can be embedded in other activities. I already had some generic validators written for FEP-ae97 API, but classic C2S introduces a new challenge: IDs. It seems that the safest option is for all id properties with local origin to be recursively removed and then re-assigned.

I tried to implement the "standard" ActivityPub #C2S API in Mitra.

It's an interesting exercise, but I am not sure if I'll ever enable it by default. Permitting clients to publish arbitrary JSON is equivalent to allowing them to publish unsanitized HTML. This may be acceptable if you're an admin on a single-user instance, but it is a really stupid thing to do when there are multiple users.

Although it might be possible to validate activities using strict JSON schemas, that would require a lot of work. You may as well create your own API that will have none of those issues.

FEP-ae97 API is also tricky to implement, but at least it offers a genuine advantage over regular REST APIs: nomadic identity. Also, its security is more straightforward because portable actors and objects are namespaced by DIDs.

@joe It is now available in the UI, "Load conversation" in the post menu

@mike

I might argue that what this represents is quite literally a "filtered view"...

That's fine, I fixed it on my side.

However, now I'm getting 403 responses when ?posts=true is present. At the same time, unfiltered collection can be retrieved without issues.

My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right.

The normalization algorithm recommended in FEP-ef61 removes query parameters because there is a magic query parameter gateways, which is used for location hints:

I thought that there will be more magic parameters and decided to "reserve" the entire query component (quoting section 'ap' URIs):

The query is OPTIONAL. To avoid future conflicts, implementers SHOULD NOT use parameter names that are not defined in this proposal.

But of course, we need them to filter collections, so this is not a hard requirement (SHOULD, not MUST)...

But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.

I think a filtered view is fine, but you could also choose to not publish this collection - it is not required by FEP-f228. Other implementations should be able to backfill conversation using the contextHistory property.

@mike I see activities, but I figured out why. The URL is normalized before fetching and ?posts=true parameter is removed during the normalization.

This is because query parameters are not significant in 'ap' URIs:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#comparing-ap-uris

Not sure how to deal with this. I think collections shouldn't have query parameters in their IDs, but query parameters should be allowed in collection views (when filtering is applied).

@mike

Yes, whenever the context element is referenced from a naked object per the current FEP-f228.

I tried to fetch context from one of your (private) posts, but the collection contains activities:

but trying to still provide reactions since our software considers them to be an integral part of the conversation

One way to provide reactions when only "collection of posts" is available is to use likes and emojiReactions collections, but I doubt that any implementation would actually resolve them.

@hongminhee

>So I would not phrase it as “documentation or multicast addresses are always practical SSRF targets.”

But could they be, even in theory? I found that 100.64.0.0/10 is indeed used for private networks, but it seems that allowing requests to documentation or multicast addresses has no security impact.