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

@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

I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID. (ie, moving it from example.com/1 -> example.com/2)

An Update activity does not allow ID updates because it would lose the reference to the original one. (It can be massaged by using an Origin property, but I don't like that).

Another option would be to use a Move activity (which is defined as moving objects between collections), where the Origin property is the object itself instead of a collection. (I like this behaviour better, as it requires less divergence from the spec)

#ActivityPub #fedidev #ActivityPubDev

Is anyone aware of a FEP for that?

#ActivityPub #ActivityPubDev #FEP

There are some implementation details in my storage layers that would prevent this problem from happening, I think. The main one being that the only way to change the public key of an actor is to update the actor itself, the key does not exist as a stand alone object that could be overwritten maliciously.

There might be some corner cases, but I'll try to come up with some tests.

@silverpill I can't really understand your example. The client doesn't have access to other actor's private keys, so it shouldn't be able to sign requests. Or you're thinking for the case of a client that is used by multiple users, *and* it stores private keys...

My clients generally use only OAuth2 for authorization to the service their users belong to and they don't do "signed requests" to other servers (because they don't really have access to the private key in the first place).

@marius

@silverpill the old way is just an Image with summary and name: https://marius.federated.id/uploads/basking-snick

Which then can be set as an attachment to a note.

The new way is slightly more complicated and I upload multiple versions that get set as URL values on an original Image:

https://marius.federated.id/uploads/bread-top-july

This one can also be attached to a note or whatever.

(if you view them in browser you get a raw image for the first, and an html documen for the second) With json+ld accept header you get the raw objects.

@marius

@silverpill so for the Pixelfed use case where usually there are multiple images, I upload them as separate images, and then aggregate them as attachments to a Note.

I think the difference to Mastodon&co. is that for GoActivityPub services, the images are not embedded and exist as stand-alone, dereferenceable objects

@marius

@silverpill and if you remember from last time we talked about stuff, the structure of these operations is decided in the clients, because the GoActivityPub servers are just (mostly)dumb pipes to the web and the rest of the fediverse.

@marius