Notices by marius (mariusor@metalhead.club)

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

@silverpill yes to first question, and no to second question because collection pages are indeed dynamic. When a collection gets retrieved from storage, if there are filters on it, they get applied and the resulting object becomes a collection page where first, next, previous are computed dynamically based on the filters.

I haven't found a good method to do away with this conceit yet.

@silverpill collections for GoActivityPub are not really special. A collection is an object which can be operated on with most of the Activity vocabulary to various degrees of success (based on what's in the spec, or based on what felt sensible at the time).

The only way in which they are *special* is that when processing activities the collection ID gets extracted from the actor it belongs to, and gets operated on (for example to add an activity to an outbox or inbox).

@silverpill basically a storage to be able to work with GoActivityPub needs only 4 operations (the docs have 5 including Create, but that will go away soon):

Load (IRI, Filters),
Save (Object)
AddTo (Collection, Object)
RemoveFrom (Collection, Object)

https://pkg.go.dev/github.com/go-ap/processing#Store

@silverpill I allow all collections' properties to be modified with Update activities with the exception of the items property itself. For those I allow Add/Remove/Move, etc.

I don't see a reason to make a distinction between what you call views and containers.

If there would be a distinction to make, I would consider views as random object arrays that are accesible at a certain URL (and I would add them in the Streams property of an Actor). Instead of a generated CollectionPage, you would only get its items.

pro@dansup@mastodon.social

@silverpill there are protocols that people complain about, and protocols that nobody uses. From a couple of months ago: https://metalhead.club/@mariusor/114912833075947072

@silverpill I feel like validating that if they exist, they should both point to the same actor is a better strategy. (Which I think is what I've been doing in GoActivityPub)

@marius

@silverpill there's no particular reason, that's how they came out of the random object generator.

It's not really against spec to have attributedTo on an activity. Why do you reject them?

I'll probably streamline it to just the actor, to keep the tests to minimal relevant details, so thanx. :)

@marius

Well, after an initial failure, my #NLNet grant application for #GoActivityPub has been accepted under the NGI0 Commons Fund. 💪

This means that for the next months my main focus will be fully on making #ActivityPub in the #Go programming language easier for other developers.

If you're one of them, reach out, I want to know what you struggle with and how I can help with that.

https://nlnet.nl/thema/NGI0CommonsFund.html#:~:text=GoActivityPub%20%E2%80%94%20Help%20people%20develop%20Fediverse%20software%20in%20Go

For #ONI the no fuss single user #ActivityPub service, I wanted to migrate from my custom hodge-podge of JavaScript logic for building CSS themes from images, to something a little more credentialed and battle tested.

Then I looked over what the Material library would generate and I begun to reconsider.

Material is so unsipired, it defaults to such samey, generic norm-core color palettes that it's difficult to see any changes even between vastly different images.

I think I'll just improve my own algorithm because, frankly, I want more GeoCities and less Enterprise.

https://material-foundation.github.io/material-theme-builder/

> - Recipient: trust embedded object only if the wrapping object has the same owner.

@silverpill no, dereference object and use that instead. The canonical version of an object is the one retrieved from the originating service.

Mastodon has popularised this behaviour where embedding collections (like your replies) is done by servers in the name of "optimizing" for request counts. But this introduces issues and personally I think it's a "code smell" for ActivityPub. Embedding should be restricted to anonymous objects. When an ID exists it should be used most of the time.

@technical-discussion @julian @grishka

@silverpill do you mean that the "malicious" attachment is not a facsimile of an actual note produced by that actor, but a forgery?

In these cases, I'll agree with
@grishka that some validation based on the ID should be necessary.

For embedded object attachments on the other hand (like mastodon produces), probably the validation needs to check that attributedTo corresponds to the one of the parent object or missing.

Interesting corner case.

@technical-discussion

@silverpill yet it does. The grouping of the activity types by domain is quite useful and gives a good indication about what/how they can/should be used.

@smallcircles

@silverpill do you have a citation for that? I always interpreted them that they're parallel, but maybe I missed something.

@smallcircles