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

@silverpill I see.

My ActivityPub library unfortunately relies on fresh copies of activities when operates on them, so it usually tries to fetch them (again).

I'll try to see if relying on the local copy is enough - which it mostly should I think.

Also let me know if you want me to write a quick spec about how I operate ACLs logic on the activitypub objects, which I think I mentioned multiple times, but never really bothered to formalize into a document.

@silverpill are your follows not accessible for retrieval, or am I doing something wrong with the authorization when trying to fetch them?

I tried responding to your Follow and my errors show: https://paste.sr.ht/~mariusor/ad2da3532ffe02e269f8523cf8d1190b7d09c678

Can you have a look at your logs if there's a problem on my end and let me know what I'm doing wrong?

@marius

#Oni the single user ActivityPub server, is getting some improvements on directly running it out of the box without requiring any set-up steps.

It is now available on the first run and every modification can be done afterwards using client to server #ActivityPub calls. Yay!

Reminder that there is a demo instance up, and running my sporadic blog: @marius

@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