temporary placeholder
1 Like
- I think this can be generalized to all kinds of fediverse applications using the mechanism described in FEP-0499. Is there a reason for using a domain-specific solution (FEP-1b12 Announce)?
- Why object is a collection? An array of activities would be more concise.
- The second example is named "New and improved fep-4248-style POST". Did you mean fep-1a11?
This FEP documents something that PieFed already does and as such it is a bit limited in scope and intended to optimize the kind of federation that FEP-1b12 involves - many frequent votes sent from a community using an Announce. FEP-0499 is great for Mastodon-style federation where a note can go to multiple inboxes but that very rarely happens in 1b12 land.
object is a collection because it’s not allowed to be an array, according to the spec. Initially it was an array (and PieFed still accepts that) but discussion with other 1b12-using devs convinced me to switch to a collection.
fep-4248 is an older name, I’ll fix that!
1 Like
Where are you getting this information? Common fediverse softwares might not handle it correctly, but the spec makes no requirements like what you say. In general, anything not marked “functional” is theoretically always an array, even if it is serialized as a single value or object/reference when the array contains exactly 1 item.
What is “Mastodon-style” about this, and what problems does it pose for 1b12? Are you saying that in FEP-1b12 implementations, activities are only delivered to a single recipient? That doesn’t sound right.
1 Like
Are you saying that in FEP-1b12 implementations, activities are only delivered to a single recipient? That doesn't sound right.
Traditionally, yes. If I like something it goes to the distributor server only, and that server takes care of relaying the activity.
Implementors that straddle threadiverse and microblog send it to all followers and the distributor server.
That’s only half of the equation, though. You send an activity to the distributor, okay, that’s one recipient. But then the distributor ostensibly distributes it to more than 1 recipient, right?
Yes that's correct, the distributor relays it to all community followers.
I was thinking of a different shape of an Add activity, where object is an array. The target could be a single inbox if there is only one recipient.
(we discussed this option with @trwnh but unfortunately it has not been included in FEP-0499)
I think it can be included, although some questions about the order of insertion since as:object isn’t ordered by default.
1 Like
I’m interested in a more general inbox batching mechanism, where you can send multiple activities of any type from multiple author actors to an inbox kind of like how Matrix transactions work.
@rimu1 Since FEP-1a11 documents PieFed behaviour and has an intentionally limited scope, I’d imagine that you wouldn’t be open to expanding it to remove the restrictions on activity type (Like/Dislike/Undo) and removing the requirements regarding 1b12 Groups?
@trwnh I’ve heard you might be interested in this for inclusion to your FEP-0499? It seems there was some intention of this due to the line:
POST an Add activity where the object is at least one activity to be delivered
If not, I am happy to publish my own FEP.
Thanks both of you 
FEP-0499 makes no restrictions to what is already allowed by spec – it just carries all the same considerations on why you might or might not have multiple objects. What is the proposed change to FEP-0499 here? As far as I’m concerned, it’s already possible to do this:
{
"type": "Add",
"object": ["activity", "another-activity", "some-other-activity"],
"target": ["inbox", "another-inbox", "yet-another-inbox"]
}
…with the same caveats around lack of ordering and so on.
1 Like
Ah sorry, I wasn’t very clear. I think I do want a FEP that does resolve those caveats, but resolving those in FEP-0499 might not be the best place. Thank you! I think I will come back with a draft FEP soon.