Yes, and it’s a subtle difference by design. The assumption here is that most users reading this topic/post don’t necessarily need to know right away that “this post is coming from a user outside this community”. It’s fun to know as an admin or as someone implementing the feature, but most people want to focus on the content. So we opt to be relatively quiet about the ActivityPub technicalities of a post.
2 Likes
Then my users are different. They defenetly wanted to know. But that must be an example of cultural differencies and how we Finns are close to asocial behaviour (by american content creators, because we have zero ability to small talk in US-magnitude 
).
But it was relatively easy to tune using CSS, so defaults are fine (and one solution is now here if someone ever wonder same thing).
2 Likes
I replied from Mastodon to a post from Discourse and the reply does not appear in Discourse. Is it a bug, or maybe such a feature is not implemented yet, or maybe it’s not planned to implement such a feature?
It is bug or somethin else. I just had a discussion where topic was published to Mastodon, got comment from there, I answered to topic, and that was visible there too.
Standard question: do you use recent version?
1 Like
Yes, I freshly installed the plugin, although I had to use this fork (PR pending) in order to make it work at all: GitHub - kuba-orlik/discourse-activity-pub: Adds ActivityPub support to Discourse.
2 Likes
Hi, can you help answering some questions loosely related to moderation that I haven’t been able to find answers for, please?
- Once a post has been federated, can it be moderated by the local admins? I mean, edited, hidden, deleted…
- What happens if the post is edited in the origin instance? Is it updated in the federated instance?
- If the moderators want to contact the federated user using the flag option or message/chat, can they? Or are these remote posters not actual users in the local instance?
- If I have an account with the same username and email address in two instances federating, they will be still considered as two different accounts in each instance, right? There is no way to “merge” them.
- yes
- yes (or should)
- no, but you can delete a problematic actor (in Mastodons other users can report, but what happens depends of admin in that end)
- Discourse never sees emails thru ActivityPub. Instead of that there can be several
icaria@…where ”domain part”, name of instances, changes, and all of those accounts are still own by same person. You can’t merge those accounts because then you would actually ban servers to get topics/posts.
1 Like
Ok, we have enabled the plugin in our instance, we have created an actor connected to a tag, and we have federated our first post to the Fediverse. Very exciting! And impressive.
Some questions (that might be suggestions for missing features, but I’m still trying to understand what is available):
As a Discourse user seeing the federated topic, is there a way to obtain a link to the corresponding toot (message) on Mastodon, for easy boost there? I couldn’t find it in the small log added to the topic:
As a Mastodon user seeing a toot coming from Discourse, is there an easy way to find the Mastodon account of the actor to follow? They can see the account of the poster, but not the actor’s. If they follow the link to the forum, I couldn’t find a way to deduce how to find the actor.
Why is the plugin boosting all the replies, instead of letting them be just replies, typical “quiet public” replies? These boosts create a lot of extra noise for those who follow the actor on Mastodon.
What is supposed to happen when a Mastodon user starts a new post (not a reply) and mentions the actor’s account or the account of a Discourse user?
Finally, this doesn’t look normal, and we are getting plenty of them (more than hundred in a few hours)
Job exception: stack level too deep
activesupport-7.2.2.1/lib/active_support/core_ext/object/blank.rb:166:in `present?'
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/json_ld.rb:57:in `base_object_id'
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/json_ld.rb:58:in `base_object_id'
(snip, dozens of these)
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/json_ld.rb:58:in `base_object_id'
/var/www/discourse/plugins/discourse-activity-pub/app/jobs/discourse_activity_pub_process.rb:25:in `process_id'
/var/www/discourse/plugins/discourse-activity-pub/app/jobs/discourse_activity_pub_process.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job'
sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track'
sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke'
sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local'
sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in <class:Config>'
sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats'
sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call'
sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global'
sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare'
sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch'
sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt'
sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt'
sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one'
sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run'
sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog'
sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread'
If you click the “Note” label in that screenshot you’ll get a link to the Note object on Discourse, but I’m not sure that’s what you want. Could you explain a bit more about what you expect to happen? Maybe share a little user story about what you’re hoping to do.
Do you mean the Discourse user? You can’t follow Discourse users currently.
Could you elaborate on what you expect to happen here? Perhaps with a user story.
This should be addressed when this is merged.
1 Like
Is it? Or is it basically same as earlier Job exception: stack level too deep questions?
1 Like
Indeed! I had missed the previous report. PR coming shortly.
1 Like
It happens, too much on a plate 
Thanks.
1 Like
Sure!
As a Discourse user who also happens to have a Mastodon account, I see a new federated topic on my Discourse, and I want to quickly boost it (reshare it) from my Mastodon account, so that all my Mastodon followers know about it and maybe respond from their Mastodon accounts, bringing a lot of federated feedback to the topic on Discourse (and maybe a few of them who didn’t know about the forum will join Discourse as a result!)
Ok, to do this, the user needs to easily find a URL that they can paste to their Mastodon client search box, which will serve the federated toot (message) corresponding to the Discourse post.
I can’t find this URL in the Discourse interface. The only easy way to boost a federated post from Discourse I have found so far is to be already following the Discourse actor and have the post on my Mastodon timeline. This is ok for those who already follow the actor, but not for those Discourse users who aren’t following the actor yet.
I hope I was able to explain the problem and not confuse things more. 
I’ll post the user story about the continuous boosting later, after understanding better the current behavior.
1 Like
If I understood right you can’t barely find anything that way from Mastodon.
For me the issue of this kind is conversation itself. Because everything are reboosts I must find the first post before I can get the whole topic, because comments of a reboost are never shown to followers. So that conversation will be vanished.
And if I reboost a comment from Discouse it will shown by ”user-actor” that can’t be followed.
That, and defenetly lack of (hash)tags are the major questionmarks now — for me, anyway.
1 Like
Ok, I have found the link I want… in the replies, but not in the top post:
In the replies, it’s the federation icon on the top right corner, next to "22h"in this screenshot.
If you click it, you get this dialog:
Which indeed points to the reply on Mastodon: icaria36 🎶: "@icaria36@the.socialmusic.network This is a test …" - SoNoMu
I’m missing the equivalent icon & link for the top post. It’s probably somewhere obvious but I can’t find it. 
EDIT:
Ah, wait, that link appears only for posts coming from Mastodon, not for the Discourse native posts. I just realized that the tiny icon has a blue and a green version to differentiate this. Blue-green is not a good color combo to distinguish such a tiny icon. My desktop monitor is pretty decent, I don’t have color blindness, and yet I have only noticed the difference now, when looking in detail these icons.
For me, one big problem is that…
As a Mastodon user replying to a federated Discourse post, I want to receive a Mastodon notification if anyone replies to my post or mentions me on Discourse.
Right now, Discourse users’ replies to Mastodon users’ posts are very likely to be missed by the Mastodon users being replied, because they see no notifications even when they have been repiled or mentioned. This makes actual conversations even more difficult that they already are on Mastodon – because you don’t even know someone has replied to your comment. Again, unless I am missing something.
BUT please take all this simply as feedback for improvement. This plugin is already impressive, we are keeping it, and we are happy to help reporting problems and testing new features. Thank you very much @angus & team!
1 Like
What is the difference between “Publish” and “Deliver”? Here is a screenshot of “Topic Admin”, of a topic already published but with a post… not delivered? The post is correctly federated on Mastodon already, and I wonder what happens when the admin clicks “Deliver Post #1”.
Both publication and delivery happen automatically if you post in an ActivityPub category or tag (with relevant settings). The distinction between the two, and these admin controls, are for flexibility and specific use cases.
Publish = the post is available on the fediverse.
Deliver = the post is delivered to the followers of the relevant actor(s).
That action lets you deliver the same post whenever you like, including after it is already delivered. There are various use cases for that, for example:
-
You initially published a topic without delivering all of the posts in the topic to your followers (because you didn’t want to spam them). You can then deliver individual posts.
-
The post was published prior to a new set of follower(s) following your actor. You can deliver the same post again.
If you click on “Topic Info” for that topic you should see that the post was already delivered if the post is already federated on Mastodon.
2 Likes
Ok, now we have a real user story from a real user that explains the problem very well.
If we wanna share a particular federated post to Fedi, anyone know how do we do that? I tried:
- looking at the profile of @fediverse@the.socialmusic.network - no posts visible
- looking at my own socialmusic profile - no posts visible
- looking on the Discourse forum for a “share” button: the URL isn’t recognised by Masto search
2 Likes
That was me! Thanks for this exciting plugin, we are enjoying tinkering with Federation on our forum.
I had a few questions, and apologies if this has been looked at before (I searched the forum but didn’t see anything).
- On the Mastodon/etc. side, how are private, followers-only, unlisted posts handled?
- For a privacy-conscious user, say someone running Gotosocial, how are their federated replies handled?
I’m particularly thinking of consent issues: if someone prefers not to have their posts searchable on a public forum. They might not be aware that the topic they’re replying to is publically visible on Discourse. The Discourse users’ posts are well marked, but if I reply to an AP user in the same thread, I might miss that it’s originally a Discourse topic.
3 Likes