Conversation
Notices
-
@p @Terry @colonelj @sjw @feld @iamtakingiteasy @colonelj @lanodan @Moon User-specific inboxes were a mistake. They literally serve zero purpose since the scope/list of recepients is already defined in activity that's being sent out.
-
@p @Moon @Terry @colonelj @colonelj @feld @iamtakingiteasy @lanodan @sjw Imagine if you had to make a SMTP daemon listen on different port for each user that's using email on said server.
-
@mint @Terry @colonelj @sjw @feld @colonelj @lanodan @Moon @p Lists of recipients are all optional, I suppose those were an afterthought, when they realized pushing separate rest endpoint for every recipient isn't viable.
-
@iamtakingiteasy @Terry @colonelj @sjw @feld @colonelj @lanodan @Moon @p Even if it's optional, I haven't seen a single server that doesn't use them. In fact, when I was testing out display name updating, I discovered that if you make a new DM thread tagging a user, the activity goes to user-specific inbox, but if you reply to the same thread with the same scope and recepients, the activity suddenly goes to instance-wide inbox instead.
-
@iamtakingiteasy @Moon @Terry @colonelj @colonelj @feld @lanodan @p @sjw So, I wonder if making an experimental patch that makes Pleroma send out activities only to instance-wide inbox if it's present would make sense. This is somewhat radical solution, but it might work.
-
@Moon @Terry @colonelj @colonelj @feld @iamtakingiteasy @lanodan @p @sjw update users set inbox = 'https://freespeechextremist.com/inbox' where ap_id like 'https://freespeechextremist.com/%':_insane:
Not exactly sure if this'll make the destination server throw 500 due to some signature errors or not.
-
@mint @Terry @colonelj @sjw @feld @colonelj @lanodan @Moon @p Sounds like an inconsistent implementation, rather than what spec described.
-
@mint @Terry @colonelj @sjw @iamtakingiteasy @colonelj @lanodan @Moon @p signatures are handled by a Plug that executes earlier in the request pipeline and literally both the instance-wide inbox and the user inbox are mapped to the same functions
-
@feld @Terry @colonelj @sjw @iamtakingiteasy @colonelj @lanodan @Moon @p Then if the culprit is priority activites patch not checking whether the activity is already send to shared inbox (or vice versa), that might be a viable bandaid until the code itself is fixed.
-
@feld @Terry @colonelj @sjw @colonelj @lanodan @mint @Moon @p Yep, that is a reasonable way to implement it, user-specific inbox only adding one implicit `to` for server logic.
Also whole AP spec type dynamism makes it rather unpleasant to work with, every field may technically be an IRI, an object, a list of IRIs, a list of objects, or not be there at all, then there are JSONLD shenanigans with extra fields and field schema prefixes on top of that. A fully *compliant* implementation would be woefully inefficient, having to deal with all that extra bulk.
-
@iamtakingiteasy @Terry @colonelj @sjw @feld @colonelj @lanodan @Moon @p In practice, a compliant implementation is copying whatever the fuck Mastodon is doing. Maybe it's for the best, considering how much of a clusterfuck the spec is.
-
@Moon @Terry @colonelj @colonelj @feld @iamtakingiteasy @lanodan @p @sjw This wouldn't have done anything since the Enum.uniq() dedupe was also missing.
Yukkuri
feld
All ０７６萌ＳＮＳ content and data are available under the