Post · bonfire.cafe

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

#fedify #fedidev #c2s #activitypub #fediverse

marius

@mariusor@metalhead.club · 3 hours ago

@hongminhee like I mentioned in a thread where Evan and Reiver were talking about this, I think having a mediaUpload that has a very similar behaviour to an inbox/outbox, but with one **small** changed detail is a bad API.

I would prefer there's either a two step process: upload media first, use resulting token in an object create, or use the outbox with for the binary data upload directly... The first one seems saner to me.

kopper :colon_three:

@kopper@not-brain.d.on-t.work · 3 hours ago

@mariusor@metalhead.club @hongminhee@hollo.social you don't even need a "token" concept specifically, the media upload could internally as:Create an as:Document (but not broadcast it) you can then refer to or inline as needed

marius

@mariusor@metalhead.club · 3 hours ago

@kopper token can be anything: an URL at which the media can now be found, the "template" json document Evan was talking about with the URL filled in, etc... Whatever would make the most sense I guess.

@hongminhee

marius

@mariusor@metalhead.club · 3 hours ago

@kopper now that I had to think about it for 10m, I really like the idea of getting back a templated object that can further be amended by the client and sent in a Create.

*By templated I mean an "incomplete" object which has filled only the properties that make sense: ID, URL, MediaType, Type, AttributedTo,etc...

@hongminhee

kopper :colon_three:

@kopper@not-brain.d.on-t.work · 3 hours ago

@mariusor@metalhead.club @hongminhee@hollo.social URLs to AS objects makes the most sense to me, as you can Just (assuming valid JSON-LD handling across the ecosystem) paste the link into whatever property to federate it immediately without needing to load more data

and the media uploader can do things like introspect width/height/blurhash out of the uploaded file into the document itself, instead of moving that logic to the client (although I imagine it'd be a good idea to allow the client to as:Update the resulting documents to add more metadata if it has to)

1+ more replies

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · 3 hours ago

@mariusor I agree. We probably need a FEP for this?

marius

@mariusor@metalhead.club · 3 hours ago

@hongminhee I haven't reached that point in GoActivityPub development to really think about it.

Currently for binary uploads I use world's hackiest hack™️, where I encode the media as a base64 media URI and set it as the Content of a Image/Audio/Video object that I send through client to server.

So far this has worked well enough between the clients and servers *I* developed, but I can't really ask anyone else to support that.