Post
@mariusor @hongminhee so, what's simplest to me is to keep the structure that was designed 8 years ago.
If you would like to propose an alternative, it's incumbent on you to make the case for it.
I think what you are describing is fine, btw. It is even compatible with the structure Christine developed. If the media upload gets a POST without a JSON-LD part, just store the contents and return an URL that can be used in a later `Create`.
@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.
I hope you write that out! But people should implement the API we have now.
I hope you write that out! But people should implement the API we have now.
@evan I did on reiver's comment on github: https://github.com/w3c/activitypub/issues/578#issuecomment-4366469692
It's a compromise between the current SocialCG proposal, and what I said above.
Do you think it warrants it's own ticket?
@mariusor @hongminhee yes, it should be a separate ticket.
I don't like your proposal for multiple reasons:
1) It doesn't include addressing, so the upload server doesn't know how to enforce authorization requests. Is the file for followers? Only addressed accounts? The public?
2) What happens if the client doesn't post the `Create` activity?
I think it's better to keep it all in one transaction together.
@mariusor @hongminhee yes, it should be a separate ticket.
I don't like your proposal for multiple reasons:
1) It doesn't include addressing, so the upload server doesn't know how to enforce authorization requests. Is the file for followers? Only addressed accounts? The public?
2) What happens if the client doesn't post the `Create` activity?
I think it's better to keep it all in one transaction together.
@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.
I’m not developing against ap specifically but do keep tabs
I think the two part process makes sense and that’s how I’m approaching my ap adjacent media explorations
The core is the idea of an array of posts, where each post could be a different media type, and so I upload media first and once I have what we can call a permalink, I put that in the actual post to create the reference from the top level post to embed the media
My biggest annoyance as someone that really enjoys media production, is how bad media is across the fediverse.
I’m a firm believer that how bad these tools are for people like me is why this place doesn’t grow beyond people that can stomach primarily text based relationships.
Install bonfire.cafe
Get the full app experience
