Notices by marius (mariusor@metalhead.club)

@wowaname I find that perfectly understandable: because all printable ASCII characters form a subset of Unicode characters, we can infer that the set of all possible URIs is included in the set of all possible IRIs.

I'm not sure why you're convinced that not all URIs are IRIs.

@silverpill

@silverpill @wowaname what exactly is the problem with calling them IRIs?

> ActivityPub shares the same URI / IRI conventions as in ActivityStreams.

From: https://www.w3.org/TR/activitypub/#objects

And following the link there, we get to:

> Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. There are two special considerations: (1) when an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as an "id" value, it MUST NOT be so mapped.

https://www.w3.org/TR/activitystreams-core/#urls

@rysiek I think an "Update" for the new preferred username went through to all instances and it's basically the same actor.
@liaizon

@silverpill I have that in my brutalinks link aggregator, however it doesn't work transparently for the whole fediverse because there isn't yet a dynamic way of registering an OAuth2 client[1] that would work with all web-finger capable services.

[1] there actually are at least two: RFC7591, and also IndieAuth

@hongminhee

@silverpill also Mastodon own's dynamic client registration is slightly different than the RFC I mentioned previously, so a client which is RFC compliant would not work with Mastodon instances. :D (another one for the pile of mastodon quirks)

@hongminhee

@Polychrome sorry, I don't know why I replaced netsurf with dillo in my head. :D

@Polychrome I think the browsers that don' support javascript get a pass automatically. Probably dillo supports just enough to trigger the protection, but not enough to actually solve the Anubis PoW. :(

@silverpill why does a "primary language" need to be specified? I think that if there is such a thing, it should be the language in which the client views the object or otherwise none of them should have special importance.

@hongminhee yes, I guess. However why did you consider the recipient as the right entity to do the signing?

In my mind, this action means that they "vetted" the received activity and decided to forward it, when in actuality it's the server that does both of those things. Ie, in my opinion, the server - through its instance actor - is the entity that assumes the burden of attestating the validity of the forwarded Activity.

I think that servers operating activities on behalf of actors, without these actors explicitly performing an action is a breach of trust between the two.

@silverpill guilty on all charges.

1/ signed by the instance actor - to decouple key verification from processing the activities (and add a modicum of anonymity on behalf of whom the request is done)
2/ No preferredUsername because naming things is hard (and the instance is named through its url)
3/ mixed keys, well, I changed the instance key to mastodon compatible a while back

@silverpill I changed the logic of fetching keys to use the same actor as the one sending the S2S activity.

....aaaand added a preferredUsername on the instance actor - which shouldn't affect you any more.

@silverpill invalid actor on my side or on yours?

@silverpill

https://federated.id/activities/6191a096-ca31-4ae7-8b3c-c7db9c6aae2b

@silverpill sadly it didn't make it to you:

Feb 08 21:46:12 DBG Starting dissemination to remote collections. log=processing
Feb 08 21:46:12 WRN Request did not meet this resource's requirements. iri=https://mitra.social/@silverpill/inbox log=client status="405 Method Not Allowed"
Feb 08 21:46:12 WRN Unable to disseminate activity invalid status received: 405 log=processing
Feb 08 21:46:12 INF Pushed to remote actor's collection https://mitra.social/@silverpill/inbox log=processing
Feb 08 21:46:12 DBG Finished dissemination to remote collections. log=processing
Feb 08 21:46:12 INF All OK! log=fedbox

@silverpill I corrected the actor IRI, but it still didn't work:

It looks like mitra rejected the signature of that actor.

https://paste.sr.ht/~mariusor/fa27a9703463f68476e24574b0aa9ca9a76f59f1

@silverpill the Activity is https://federated.id/activities/22fe7abd-73d2-4508-acbc-ee683be6a3df

@silverpill this one: @clothoed

https://federated.id/actors/a1517c06-7131-4437-84b0-025837e9da39

@julian

@silverpill so I'm not missing anything, just people wanting to overcomplicate things. Sigh.

Consent is not a thing that should be encouraged through non server-side enfored mechanisms because (as we can see plenty today) bad faith actors care not about such things.

Therefore a flag on an actor/object is useless because it requires that crawlers obey it, and again, they can not be trusted to do that.

In my opinion offering this as a solution to end-users is just snake oil.

@silverpill does anyone justify in their FEPs _why_ there is a need for additional properties when ActivityPub provides multiple ones in the form of the To, Bto, CC, BCC recipients, and of the Audience one?

These form a perfect basis for access control lists and I haven't seen anything that convinced me that it's not enough combined with OAuth2 tokens for C2S and HTTP-Signatures for S2S.

@silverpill is there some glaring thing I'm missing? I fail to believe that nobody really thought of this simplest way to handle ACLs.