Notices by marius (mariusor@metalhead.club), page 4

> Second, this change allows clients (in browsers) to circumvent blocking.

@helge I was mostly agreeing with Alex, but I never thought about this and you make a lot of sense.

But, if I can propose a compromise, any ActivityPub object has an audience. We can add the members of that audience to a CORS access-control-allow-origins list and get something in between. The fediverse is blocked, the audience can still access the object.

@fediforum @fediverse @fediversenews @obale

@evan I think building reply trees would be much more simple if besides the parent, all the grandparents would be included in the "inReplyTo" of an object. It's sad that nobody does this in any of the fediverse software.

@darius @charlesrandall

@darius @charlesrandall I think I agree with @evan 's sibling comment the thread, it's not hard at all.

The server where the object that is being replied to is the place where this enforcement can be done. An object can claim that it is inReplyTo another object, but the server of the original object has authority to act on this fact. If the server doesn't add it to the replies collection of the original object, then it's other instances should not see it there. Am I missing something?

@boyter the answer to this is so simple. Interacting with any end-point needs to have an HTTP Signature corresponding to a valid ActivityPub actor. This actor should be a Service for instances of fediverse servers, an Application for non client applications, a Person for client applications like Toot! or Tusky.

This way there's a simple indicator where the requests originated and what/who needs to be blocked if the traffic is un-wanted.

@lain blink twice if you're in danger. :P

I am gathering a list of #Mastodon quirks in implementing #ActivityPub in order to submit some tickets to github.

So I would like to hear from you if you're a developer of a service that uses ActivityPub and you had issues with making it compatible with Mastodon.

(PS. This is not meant to be adversarial, but a way for improving Mastodon at least through documenting the pain points of other developers when communicating with it.)

@Gargron is it good?

@helene I think you're working with the assumption that all clients must work with all activity types. That in my opinion is wrong. Doing a "best effort" thing on what a client doesn't understand seems enough to me. Best effort being handling the properties that the client already understands (attributedTo, inReplyto, name, summary, To, CC, samd)

@ta180m

@ta180m @helene

Type as arrays is planned for go-activitypub.

https://todo.sr.ht/~mariusor/go-activitypub/165