14 lines
1.4 KiB
Markdown
14 lines
1.4 KiB
Markdown
|
+++
|
||
|
|
+++
|
||
|
|
|
||
|
|
i have a hard time deciding what ought to be the correct behavior here. maybe activitypub should have just assumed everything is deliverable as-is, but only activities get side-effects? of course there's still a problem with id generation not being fully specified... https://github.com/w3c/activitypub/issues/438
|
||
|
|
|
||
|
|
something like "generate an id for the outermost object, overriding any pre-included id"?
|
||
|
|
|
||
|
|
which is basically the current behavior and imo where the implicit-create is meant to be applied... basically normalizing everything to an activity (assuming Create by default)
|
||
|
|
|
||
|
|
so without the implicit-create behavior, you would basically POST a note or whatever to your outbox in order to assign it an id, and it would be delivered as-is without the Create. the outbox wouldn't contain only activities, it would also contain objects. this kind of makes the Create itself redundant and unnecessary, i guess? or in other words, you need to define what Create means in terms other than id assignment. this is kind of a problem because right now, Create has "surprisingly few side effects" (read: basically none)
|
||
|
|
|
||
|
|
otherwise you explicitly format every POST as a Create but you have unspecified behavior for id generation of the inner object
|
||
|
|
|
||
|
|
maybe sending a Create C2S does nothing with the inner object, but the side effect should be to assign/register the object on the receiving S2S server?
|