Notices by marius (mariusor@metalhead.club)

@silverpill sorry if I misunderstood :( I was under the impression that you're working towards embracing DIDs as identifiers as far as I remember. To my mind that moves away from "you get the canonical representation of an object by fetching the URL of its ID" to any representation of the object that passes identity proofs. (perhaps I'm wrong in thinking this anyway, my investigation on how DIDs relate to canonical object representation was cursory and incidental) That's what I meant.

@technical-discussion @heluecht @julian

@silverpill I think you're saying this from a position where identifiers in ActivityPub are no longer unique URLs and therefore "canonical representations" are harder to reason about, but in my opinion that's not where the protocol is now, and hopefully, not also in the future. And yes, I am aware of context, I am pretty sure I have one the first implementations that made use of it as a thread container, but that whole fep is over engineered and IMHO missed what I consider the obvious and simpler solution: put all parents in the inReplyTo and include all parents' authors as recipients. 🤷

@technical-discussion @heluecht @julian

@silverpill sorry to butt in, but all of this would be solved by respecting what the canonical representation of a reply thread is: the replies collection of the top post[1]. I think it makes much more sense to built that correctly and rely on it instead of trying to keep all the nodes of the network in sync with countless activities.

[1] Caveat, this requires that all replies to a post, include in their inReplyTo property at least their parent and the top post - ideally they should include the whole chain of parents to the top post.

@heluecht @technical-discussion @julian

The vocabulary part of #GoActivityPub is getting closer and closer to being able of generating and operating with custom #ActivityPub data types.

:goose_hacker:

https://go-activitypub.federated.id/lib/rfc/code-generation.html

@silverpill as one of the people that started this long thread of venting at the SWICG, I have to say that the ad-hominem is taking it a bit too far.

@smallcircles @evan

@evan if you, or your employer, are the kind of
person to ask 10c per implementation, perhaps you are the wrong person to be involved with creating the specifications in the first place.

CLAs imply that the org does not trust me, but I should trust the org that they don't rug pull the thing I contributed to and re-license it in a way it's convenient for their stake holders. No thank you.

@smallcircles

@evan it's a sad situation when valuable content released in good faith as public domain is not suitable for inclusion. Requiring people to sign a CLA is a bit of a slap in the face in my opinion.

@smallcircles

> And it does id string manipulation in an ecosystem where ids are otherwise opaque.

Perfectly acceptable critique, but I would have liked to see it in the considerations for your document, instead of assuming that you had no idea it existed.

@evan @smallcircles

@evan also I'm not sure where this idea comes from, IRIs build on the URI spec, which most definitely are not considered opaque blobs and follow a clear syntax, at least when it comes to resources referenced over http:

https://datatracker.ietf.org/doc/html/rfc3986#autoid-17

PS. If there is such a reference that I missed, can you link it to me, please?

@smallcircles

@smallcircles my personal feeling towards specifications that introduce bespoke APIs for a one purpose functionality that can be already done is that they're misplaced effort.

@evan, or the SWICG, have a tendency to ignore previous art when they come up with these random specifications. That document of mine you linked to was actually turned into FEP-6606, so it's as visible as anything would be to the SWICG.

I already argued enough about the media upload end point that I don't have the energy to drop what I'm working on and jump on the mailing list and IRC to draft and present a coherent case for why I think they are bad.

@smallcircles I might be off base here, but from where I'm standing, when they embark on their roles, their primary mission becomes to keep track of what's happening in the community.

It's their job to read all the FEPs that are relevant to a particular piece of functionality they're discussing. Sure, the FEPs might not be useful, but IMHO they need to include references that they did their due diligence.

As a community member I can offer my thoughts if asked for, but I think it's unreasonable that it's me that needs to keep track of everything they're working on, and take time out of my own stuff to author feedback unprompted.

@evan

> The folks at the SWICG are also just volunteering their time

Oh, for some reason, I thought they get paid for their time. Apologies for being so blunt then...

@smallcircles @evan

> ActivityPub is simply not designed for generic servers.

@silverpill you're overthinking it. Of course they're possible to do at the same level as PDS's are. Storing the JSON-LD as an opaque blob after the server handled what it understands from it is the obvious solution.

Maybe you mean that generic clients might be difficult to implement - which I bet is the case for every dynamic protocol ever, including XMPP and ATProto.

@daniel @movim @django

@silverpill skimming over that FEP leads me to think that you imagine there's a world in which servers can operate dynamic activities side-effects based on random bits of json. And, with all due respect to JSON-LD and RDF, they're not at the point where random computing operations can be encoded through them. So I'm not sure how you imagine to tell a "generic server" that for activities of type "Blink" they need to blink the power LED, but I might just be lacking the imagination. Is there another messaging protocol that you know of where this "generic" mechanism exists?

gultsch.social @movim @django

@silverpill what prevents the original gateways= being used multiple times?

@silverpill yep. Your bane, more JSON-LD bullshit. :D

@grishka

@silverpill are we allowing Mastodon guide ActivityPub development again, when alternatives exist?

@grishka

@grishka yeah, ed25519 for some of my actors supported by GoActivityPub. (Well, it could be anything that the Go crypto library supports, but only ed25519 is in some use)

@silverpill with the risk of repeating myself: the organization should be the server!11

@silverpill in the context of Mastodon's FEP, perhaps cache poisoning could be a problem, but from the context of ActivityPub, there's no "cache poisoning" because the canonical version of an object is the one the server retrieves explicitly based on its ID, anything else is hearsay and should not be trusted by default.

Also I find very hard to reason about what you call "cache poisoning" when the entity that serves the object is the same with the one that sends the activity.