Discussion
@kopper @hongminhee i think you could upload the binary media to one endpoint, get an https: url for its Location header, and turn around and Create an Image or whatever with that Location header as the url.href of your new Image
although now that this topic comes up: there is a lack of clarity around "image" vs "image representation", since Image assumes "image" and not "image representation". as:url is nominally that "representation" and i wish it was better defined that this was the case...
@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.
@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
@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.
@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...
@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)
@mariusor I agree. We probably need a FEP for this?
@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.
Install bonfire.cafe
Get the full app experience
