Issues with Discourse AP plugin receiving the whole thread?
-
Cross-referencing the thread where this came up. And will then search the discussion elsewhere on the fedi, to see what I missed.
FEP-a427: Server Domain MoveUgh, Discourse is not receiving the whole thread. Please take a look at @jonny@neuromatch.social's replies on ActivityPub.Space
Follow up: This follow-up by @jonny is the missing thread part, related to the quote above:
-
Cross-referencing the thread where this came up. And will then search the discussion elsewhere on the fedi, to see what I missed.
FEP-a427: Server Domain MoveUgh, Discourse is not receiving the whole thread. Please take a look at @jonny@neuromatch.social's replies on ActivityPub.Space
Follow up: This follow-up by @jonny is the missing thread part, related to the quote above:
It was because Jonny (on Mastodon) replied directly to me (on NodeBB), bypassing SocialHub (on Discourse).
This is a Mastodon problem and is one in a series of reasons why Threadiverse-Microblog interop sucks at present.
-
It was because Jonny (on Mastodon) replied directly to me (on NodeBB), bypassing SocialHub (on Discourse).
This is a Mastodon problem and is one in a series of reasons why Threadiverse-Microblog interop sucks at present.
does it make sense for nodebb to forward to socialhub here, even if mastodon didn't address socialhub?
-
does it make sense for nodebb to forward to socialhub here, even if mastodon didn't address socialhub?
The intent is for the content to be shared to all relevant parties. Since Mastodon relies on direct addressing it also relies on previous replies to maintain the recipients list via mentions.
Since threadiverse software sends the relevant group actor in audience, Mastodon could include that in its delivery targets and this would be resolved.
-
The intent is for the content to be shared to all relevant parties. Since Mastodon relies on direct addressing it also relies on previous replies to maintain the recipients list via mentions.
Since threadiverse software sends the relevant group actor in audience, Mastodon could include that in its delivery targets and this would be resolved.
yes, it would "resolve" the immediate issue if mastodon addressed both nodebb and socialhub. but in the case where mastodon doesn't do this, nodebb should still be able to forward to socialhub, no?
-
yes, it would "resolve" the immediate issue if mastodon addressed both nodebb and socialhub. but in the case where mastodon doesn't do this, nodebb should still be able to forward to socialhub, no?
> @trwnh@socialhub.activitypub.rocks said in Issues with Discourse AP plugin receiving the whole thread?:
>
> nodebb should still be able to forward to socialhub, no?I could be entirely wrong about this, but I believe there is no facility for forwarding activities to the distributor (aka the instance housing the community containing OP.)
The distributor itself is the only one forwarding activities, and it does so only via Accounce-wrapping.
I think even if I Announce-wrapped the activity and sent it off to the distributor, there's no integrity guarantee, and I think most activity IDs aren't resolvable (could be wrong about that too)
-
julian2:
The distributor itself is the only one forwarding activities, and it does so only via Accounce-wrapping.
I think even if I Announce-wrapped the activity and sent it off to the distributor, there's no integrity guarantee, and I think most activity IDs aren't resolvable (could be wrong about that too)
if you take "wrap in Announce" to be a mechanism for forwarding (instead of forwarding to inbox directly), then there still doesn't seem to be anything stopping nodebb from including socialhub in the audience, is there?
actor: type: Announceobject: to/cc/audience:in either case, the "integrity" is an separate concern and can be established in any of the ways it generally can be:
- Fetch the resource from its authoritative origin with TLS (the inbox payload's
id, or the Announce activity'sobject, ...) - Include an embedded proof in the content with something like W3C VCDI
- Include the original HTTP signature, if there was an agreed-upon way to forward HTTP signatures
- Fetch the resource from its authoritative origin with TLS (the inbox payload's
-
julian2:
The distributor itself is the only one forwarding activities, and it does so only via Accounce-wrapping.
I think even if I Announce-wrapped the activity and sent it off to the distributor, there's no integrity guarantee, and I think most activity IDs aren't resolvable (could be wrong about that too)
if you take "wrap in Announce" to be a mechanism for forwarding (instead of forwarding to inbox directly), then there still doesn't seem to be anything stopping nodebb from including socialhub in the audience, is there?
actor: type: Announceobject: to/cc/audience:in either case, the "integrity" is an separate concern and can be established in any of the ways it generally can be:
- Fetch the resource from its authoritative origin with TLS (the inbox payload's
id, or the Announce activity'sobject, ...) - Include an embedded proof in the content with something like W3C VCDI
- Include the original HTTP signature, if there was an agreed-upon way to forward HTTP signatures
Yeah well that's it isn't it, there's no way to forward an HTTP signature?
Anyway, while the practice works in theory (to announce the activity back to the distributor), I don't think any threadiverse software supports that use case. That's what I meant.
- Fetch the resource from its authoritative origin with TLS (the inbox payload's
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi