Notices by marius (mariusor@metalhead.club)

@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.

@julian @silverpill I have a stupid validator that iterates through ed25519, rsa-512 and rsa-256 methods and succeeds on first. :D

@steve I don't really understand what @silverpill wants to underscore with that FEP.

In my software I am using something like his core types for actual data types, but the differences are mostly in behaviour a server/client has in relation to them. Ie, what can one "do" when encountering such an object, and that's better guided by looking at their data "shapes". The properties common to the Object type can be used for "object things": display name, content, use URL, etc. The extra properties for Actor, can be used for actor things: addressing. The properties for Collections: for retrieval, etc.

@silverpill I think Actor should be considered a core type (for the purposes of ActivityPub) just because the whole of the ActivityPub specification is based on it and its structure.

@silverpill I feel like thinking about the problem like that ignores one of the main tenets of the ActivityPub protocol: An Actor has An Inbox. :)

@BeAware @julian @aj

@silverpill how does nomadic identity solve the problem of using multiple types of fediverse applications with a single identity?

Is it because multiple individual applications can show the same did:: ?

@BeAware @julian @aj

@silverpill I added a ticket here: https://todo.sr.ht/~mariusor/go-activitypub/296

I will need to create a test-case for it, but I think I have all I need.

@silverpill which works for maybe 1% of people that create content professionally. How are we to dar say that the fediverse needs to accessible to everyone if we put crypto-currency obstacles in front of people.

In my humble opinion, any monetization option that only deals with cryptocurrency is useless in making the fediverse a valid alternative to whale content creators that might want to migrate from traditional social media.

@benpate

@benpate see if you can come up with some sort of activtiypub vocabulary based on this idea: https://floss.fund/funding-manifest/

I'm sure more of the fediverse creator would be interested in having some monetization capabilities.