Notices by silverpill (silverpill@mitra.social)

@julian @angus It might be a post made after remote login via OAuth

The problem with duplicated remote comments seems to be gone (I am writing this comment from my own server).

However, I discovered another issue with remote comments like this one: https://socialhub.activitypub.rocks/t/1b12-vs-guppe-groups/5032/13.

Its ActivityPub ID is

https://socialhub.activitypub.rocks/ap/object/07746fd71af9af4f0789f9e4798f33ec

and its attributedTo property has the value of

https://oisaur.com/users/renchap

meaning "actor from oisaur.com created object on socialhub.activitypub.rocks", which generally shouldn't be allowed (unless this actor is explicitly authorized to do so).

I think Discourse should show the original ActivityPub ID of the remote comment when user clicks on the "ActivityPub" button. This probably affects federated activities as well.

Updating FEP-fe34: Origin-based security model:

https://codeberg.org/fediverse/fep/pulls/509

- Added "Implicit ownership" section. It covers some non-obvious cases such as inbox/outbox collections and collection pages.
- Added reference to FEP-2277: ActivityPub core types, because the concept of ownership doesn't make much sense if we don't know what is an actor and what is an activity.

#fep_fe34

@b0y The situation is more complicated than I thought. We use legacy signatures because they are compatible with cryptographic standards used in fediverse. Without the -l flag, minisign computes Blake2b-512 digest first, and the signs it. Fediverse applications use SHA-256, so the only way to make them interoperate with minisign is to use legacy format where signature is generated without hashing.

A new type of identity proof can be added, but I am not sure about minisign because it is not user friendly. Ideally, it should be something with a GUI.

@ex_06 @sendpaws @tadano

>How?

It rejects posts that are not addressed to any local user. If you see a post in mitra, it is because you are following someone and they sent it to you, or because you're mentioned or replied to.

>even just a list shared between cherry picked friend servers could be useful and not that exploitable like the very big ones

You can do this already by writing a cron job that downloads the list, parses it and feeds to mitractl add-filter-rule.

Other projects are rolling out automatic subscriptions (GtS for example), if that goes well maybe I'll add this feature too.

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.

@ex_06 @sendpaws @tadano I think that blocking of entire instances should be a deliberate action, not automatic, because shared blocklists can be abused. Mitra already prevents federated timeline spam by default, has mention controls, and I want to implement reply controls too. That should be enough to solve the spam problem.

@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