Cursed hack to fix Mastodon-Threadiverse communication
Technical Discussion
1
Posts
1
Posters
0
Views
-
If I post something to a remote community, Mastodon people reply directly to me, and it doesn't make it to the remote community. π
If I snuck in a mention to the community (but not in text), Mastodon would prefill the community mention and it would propagate correctly. π
Tell me this is a bad idea.......
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian If forwarded activity doesn't have a signature (FEP-8b32 or LD signature), you can fetch it by its ID. Mitra does this. Not all activity IDs are dereferenceable (hello Mastodon), but some are :)
-
If I post something to a remote community, Mastodon people reply directly to me, and it doesn't make it to the remote community. π
If I snuck in a mention to the community (but not in text), Mastodon would prefill the community mention and it would propagate correctly. π
Tell me this is a bad idea.......
-
@julian@activitypub.space @julian@fietkau.social well, in theory, you can have private likes and public likes. misskey and pleroma do public likes. mastodon does private likes, but then shows them publicly if anyone asks the origin site. because addressing is just a suggestion, apparently ;)
-
@trwnh@mastodon.social I thought inbox forwarding between instances was a non-starter per the AP spec because you cannot guarantee that the activity hasn't been tampered with.
I thought it must be paired with a signature of some sort.
-
> group itself be the distributor
well, naturally, i would suggest addressing both the group and its members. just like you would address both a person and their followers. or a moderated conversation and its audience. the way inbox forwarding works is that someone has to do the forwarding from their inbox. :)
> list is hidden
you don't need to know the items. that's private info, and you just need the id to be understood by the forwarder (who will themselves know the secret items)
-
@evan The groups (private groups, specifically) aspect is the reason why I brought up this topic at all β it was mostly for my understanding of the spec because to my knowledge, there weren't many collections being passed around in recipient fields; the only one being /follower, which isn't always resolvable.
The same issues would occur around private groups... a public group publishing something a /members collection would be addressable, but not a private group or one whose membership list is hidden.
All threadiverse softwares work around this by having the group itself be the distributor, and so you needn't address a members collection, you just need to ensure the group itself is addressed. The rest is implied (which HA! I bet @trwnh@mastodon.social has much to say about implied behaviour)
-
@silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s
(this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)
-
@silverpill @julian @technical-discussion
example: alice and bob on site.example each have followers collections, but alice can't see bob's followers. if alice addresses bob's followers collection, then alice's outbox can't deliver to bob's followers. alice must address bob, and bob can choose to forward to bob's followers (inbox forwarding)
if site.example has a collection of "local users" that alice can see, then alice can address it and alice's outbox can deliver to items
