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

@pfefferle that should already be the case. How does the accept header look like for you on the server? I'll double check tomorrow if I'm doing something stupid and haven't noticed until now. :D

@silverpill personally I feel like the various activity/object signing methods that get used in recent FEPs are more egregious from a size point of view, when the in spec behaviour for obtaining canonical versions of a resource is to fetch them from their server, instead of relying on random object signing that introduces so much more friction.

@hongminhee

@silverpill regarding size, ActivityPub is such a verbose protocol that the hundred or so of raw bytes you save through omitting context, are most likely negligible through the prism of connection compression. So to me that's not entirely a "valid reason".

And as developer myself, I think that contexts, even in a non valid JSON-LD implementation, offer enough guidance for building a data vocabulary for them to have plenty of value.

Do you propose we replace contexts with Open API specifications, or how do we coordinate what's a valid vocabulary data object in a federated network? And how do you propose that others discover these specs?

@hongminhee

@silverpill lol, that's simply madness to me. See the sibling reply to Julian why I think signatures, which is what I imagine you mean by "authenticated" are an unnecessary contrievance.

I meant "data object" in this context as the end-result binary data type that your application deals with, which for my preference, needs to match the structure of the incoming payload as closely as possible.

@hongminhee

@silverpill I'm sorry, I'm not aware of that and I thought I read the specs pretty thoroughly. Could you point me in the right direction for where you got this information from?

@hongminhee

@silverpill aaah, I see. I think we've had this discussion before (or at least I had it with someone else).

For me "SHOULD" falls in the category of the robustness principle: "be conservative in what you do, be liberal in what you accept from others".

So for me if you treat "SHOULD" in a spec as non mandatory you haven't really implemented the spec.

@hongminhee

> while linked data cultists harass developers about nonresolvable URLs

@silverpill I don't consider myself a cultist but I still think that putting invalid URLs in any payload where they are supposed to be meaningful is disrespectful towards anyone that consumes your API. Please don't do that.

@hongminhee

@pfefferle that seems like a weird ask for a client you want to prototype with, but indeed, BOX does not support PKCE yet.

@pfefferle if you're satisfied with using a CLI tool, you can try the client I created for GoActivityPub based servers: https://git.sr.ht/~mariusor/box

It supports OAuth2 dynamic client creation either with CIMD or with RFC7591

It supports creating activities for publishing text content and some basic loading of information about ActivityPub objects.

In the near future it will also support proxyUrl to interact with secure fetch servers, but not just yet.

@steve

@pfefferle also perhaps @django will be interested in collaborating. He's the latest to try to implement clients for C2S, and I imagine WordPress would be a sweet, sweet target for him.

@steve

@pfefferle is there a reason why you aren't looking first at the official specification?

The "soft-delete" behaviour is the actual spec conformant mechanism for deletion in ActivityPub.

What @julian describes as "hard-delete" in this FEP exists in the spec only as a side-effect of Undo-ing the original Create activity.

@raphael I think that by default if the server is not around any more the activity is no longer resolvable. As far as I know there's no plans for dropping identifying ActivityPub objects strictly by their IRI. :)

@evan

@raphael I understand that, but in the model that ActivityPub follows, where you get the canonical representation of an object by fetching its IRI (which is what I thought you referenced with your first point in the grand parent), you don't really need a signature in my humble opinion, unless your threat vector is a malicious originating server, which frankly ActivityPub has no means to mitigate as things are.

@evan

> I don't know why you'd do since they're very different resources

@thisismissem I feel like we had this discussion before.

As long as I reconstitute both, the ActivityPub Actor and the OAuth2 Client Metadata, from the same underlying data they are the same to me and I want them under the same URL.

So, as a developer, I would expect that any ontology that we make use of for building this thing we call "the Fediverse", and which need to ultimately be based on HTTP, has to respect its basic tenets: URLs represent resources and, in order to get distinct representations you use Content-Types. Spec'ing something that violates this is questionable to me.

@evan I lived in Burssels for some years, you won't tempt me with beer. 😈

@evan as of now I don't plan to come.

But I have no other obligations for February, maybe a last minute change of heart. :D

@evan yes, yes, of course. :D They go hand in hand...

I remember seeing on the SWICG mailing list a comment where this mechanism is no longer considered secure, but I don't recall the details.

For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.

The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni

@silverpill yes, I was thinking of the nomadic identity aspect when I said that.

So, for GoAP: a user wants to upload an image, it can specify recipients, the client builds an Image AP object out of that (including a reply collection) and wraps it in a Create collection, sends it to the server (C2S).

Server saves Image locally, creates all collections for the Image that are not empty in the Image (like replies, likes, shares, etc) adds it to outbox of user's Actor, adds it to local follower's Inbox or sends it to remote followers Inbox (S2S). If it's in reply to something(s) loads the object(s) and disseminates it to the recipients.

@silverpill only an actor that owns the collection can operate on it, and only the server that resides on the same host can operate on collections with that host. Ie, all the logic I'm describing refers to client to server, collections that reside on other servers are not really relevant.

And I don't know if I mentioned it before, mostly GoActivityPub focuses on the vanilla specification, the fancy use-cases in FEPs, like nomadic identity, are outside the scope until we can make use dynamic object types - which is not the case at the moment, we're limited to plain Activity vocabulary.