Just a note that we’re currently at this step
5 Likes
This is looking great!
I recently setup a Discourse server for our CoSocial Co-op that runs a Mastodon server. I ended up setting up OAuth2 plugin so we only accept logins from our Mastodon server → https://members.cosocial.ca (pretty plain new install, just “proof of OAuth”).
My question / feature request is that it be possible to stage/merge Mastodon actors into Discourse accounts, so when accounts on Mastodon reply, they can be linked / owned by the Discourse account associated.
How Lemmy Doesn't Do This
I documented how Lemmy doesn’t do this – you can interact via Mastodon, and an account is created in Lemmy for that Mastodon account, but you can’t actually login and use first class features of Lemmy with your Mastodon account.
4 Likes
That’s on the agenda…
And already in the queue for review
3 Likes
Great. It sounds like my Discourse OAuth plugin users would need to “confirm again” to interop with this AP plugin.
I think that’s perfectly fine at this stage, just want to flag the OAuth server as one more angle, as long as it doesn’t conflict. The “nice to have” would be “if OAuth with Mastodon server, then automatically link AP actor identity”. Totally future and also unique to this kind of setup!
(And apologies for not popping up the page to look at that part! Great!)
1 Like
The PR adding this set of features is now merged.
As Angus noted above, next up is user verification via OAuth tokens.
2 Likes
The problems I saw earlier with raw markdown coming through appear to be affecting meta as well. I’m following @feature@meta.discourse.org and some hours ago, this post was created that was federated from that Actor:
This showed up for me in Mastodon glitch like this:
In Elk, it looks like this; a little better:
I just started following @feature@meta.discourse.org in my pure Mastodon account now to test this, but of course that’s too late to see this particular post there. 
So the embedded markdown I saw earlier from my own install wasn’t a bad database, or if it was, it was a database problem shared with meta and thus probably not associated with my testing.
2 Likes
Yeah, I can reproduce this, I see similar output in a Mastodon instance and in Ivory (iOS app).
2 Likes
I’m not sure if this is working right. The plugin is enabled and I made a topic in a category with ActivityPub enabled, but I’m not seeing the badge next to posts (and my attempt to follow the category’s activitypub actor seemed to fail, since it’s acting like a server would if follows needed to be manually approved by a user).
It would be great to understand the end goal for restrictions, without worryig about intermediate state.
For example, I think I saw a reference in a PR that changing owners of posts will be blocked if the plugin is enabled. As an admin, I have to use that feature on rare occasions (for example, when changing category moderator, I make the new primary category moderator the owner of the category about sticky post). I’m hoping that in the end, this would show up as a delete and a repost, or even just ignored, rather than blocking the change of ownership.
I also wonder about moving posts between categories. I have to do that reasonably frequently, especially when new users post in the wrong category. I’d naively expect that it would result in one category actor removing its boost, and the new category actor adding a boost, but not deleting the underlying post, such that if someone else had seen and boosted a post, their boost wouldn’t go away just because the category actor boost went away.
Generally, it would be really helpful to know what you expect to be disallowed when this plugin is added, after the currently-specified feature development is complete, regardless of what restrictions are currently in place.
1 Like
@hello-smile6 I’m seeing the same thing with the plugin updated today:
I don’t see configuration for it, so I assume it’s a bug.
2 Likes
Thanks for the further report. I’m looking into this.
Thanks for the report, we’re looking into this.
I appreciate where you’re coming from, however
-
While the plugin is being actively developed attempting to explain things in this fashion would be unproductive as the explanation may change.
-
There are quite a few different scenarios and edge cases that the plugin already deals with, for me to explain every one narratively at this stage would take too long (i.e. effectively doing this long post a number of times). There are already over 400 different specs for the plugin.
-
Nevertheless, restrictions are often explained narratively in the comments on the PRs and commits, which I think you’re already reading.
This was discussed in some depth on the PR
I’ve restricted changing post owners and making post wikis, even for admins, in AP topics. This is because remote AP posts have to retain fidelity with the original and both actions may potentially break that fidelity.
There may be a way to make federation work with both wikis and changing post owners, however I suggest we add that as a “feature” in a future PR as it will have to involve multiplying or changing the actor associated with an object that is federated out across multiple platforms. I think we will never be able to allow changing post owners of imported ap posts (notes), as the actor/object association is not owned by Discourse, but the place the content was authored. To give an illustrative analogy, in this context, Deletion of a post associated with an imported note is less a “deletion” per se, than a choice to not show a Note.
There are quite a few different scenarios involving moving posts. I’ll handle the specific one you’ve mentioned for now, namely moving a post between two different ActivityPub enabled categories.
You’re assuming the only time a post is moved between categories is when the post is initially posted in the wrong category, and the move occurs soon after the post was made. What if, 4 months after a post was may, you move that post into another category because you want to consolidate a certain collection of posts into a new topic in a different category? Would it make sense to send an “Undo” for the original boost in that scenario?
This depends whether we’re talking about the First Post configuration or the Full Topic configuration. For the former we’ll be adding a button for the first post to be manually published to specifically deal with the category move scenario. For the latter, automatically adding a boost may make sense, I’ll think about that some more.
I understand where you’re coming from, however I’ve already shared a fair bit of detail on the end state in the Phase 2 specification above. Beyond that specification, and putting this as gently as possible, there are far too many use cases and scenarios for me to discuss them all in depth with you, and then also with the Discourse.org team, while working on them 
I will update the OP with an general overview of the expected behaviour once Phase 2 is complete.
1 Like
I’m not able to reproduce this issue. I just followed feature@meta.discourse.org from a test Mastodon account, and did not see an error (in either Mastodon or Discourse).
1 Like
It might be related to the instance I followed it from, does this instance do anything unusual?
Oh dear, in my attempt to ask a clear question, I sounded like I was asking for a lot of work. I apologize for miscommunicating. I appreciate the thoughtful response.
That was what I meant to be asking for, not ongoing detailed updates in this thread. My “after” in “after the currently-specified feature development is complete” was meant to apply to when the clarification would be valuable to have, not meaning to ask that you now describe the future state. My question was ambiguously worded. Sorry about that!
This is what I really wanted to understand: Is the end goal, broadly speaking, to restrict Discourse to only what canonical ActivityPub supports, or is it to federate from an unrestricted native Discourse experience to the fediverse on a best-effort basis? My past experience with Discourse integrations had led me to expect best-effort; now I understand that it is your plan to pursue fidelity instead, at the cost of Discourse functionality, and not just as a temporary measure during development.
I’m not assuming that. Why would four months make a difference here? It’s newly in a federated category, why would that not cause the federating category to boost it? I, at least, would have naively expected that to happen. I often see people boost posts that are many months old, so I don’t know of a particular reason this would be different.
And yes, I think it would make sense to send an Undo for the original boost. That seems to be common. (In fact, Undo on a boost and then a new boost seems to be a typical mechanism to “bump” content; unrelated to this purpose but illustrating that Undo on boost is commonly used and therefore should not cause problems to other ActivityPub implementations.)
I see the same thing right now for feature@meta.discourse.org from mastodon.cloud which I think is running plain vanilla Mastodon.
1 Like
Personally, I don’t think about it either way. Discourse.org will set the overall agenda here, but broadly speaking decisions are made on the basis of how it works, and what’s practical. If there’s a sensible and sustainable way of allowing authorship changes on all posts, regardless of provenance, then great.
Just focusing on the undoing of the original boost, that specific Undo doesn’t seem to serve a purpose? It’s also arguably a little surprising in some scenarios as my example tried to show. The intention of the category move might not be to reverse (Undo) the original “discoverability” of the content. It may be to change the organisation of the content down the line for a different reason.
To put it another way, applying an automatic reversal of the original Announce on a category change in Discourse works in some scenarios, but not others. And even in scenarios where it seems to make more sense, the original Announce isn’t really causing any harm. So pursuing the principles of least harm and least surprise it feels like just leaving the original Announce in place makes more sense. Sorry if I’m missing something though.
To think about it from another angle, I don’t think it’s right to think of Announce activities of a Category Actor as synonymous with the taxonomic role of Categories themselves. An Announce is the way a Category actor shares content with its followers, but it’s not a taxonomy itself. It’s one way content is discovered within the Fediverse. I don’t think there needs to be a 1:1 relationship between categories and the Announce activities of category actors.
3 Likes
Ah. Then it’s really a question for the team. 
That makes sense as well. I agree, not a lot of value in undoing the boost.
So it’s an edge-triggered signal; it would mean “a post has just entered this category, either by being written or being moved into the category.” That is conceptually simple.
I would then think of changing authorship of a post much the same way, then. It would be the new actor creating a new activity for the new author’s post, and there’s no particular need to do anything with the old activity made under the old author, because the old author wouldn’t be writing any edits, and shouldn’t be credited with those new changes. They didn’t actually delete their post on Discourse, so deleting the original author’s activity would not necessarily reflect some base truth. But what had been posted before by the old author’s actor would be what they had written, and there would be no reason to delete those posts. And if someone followed the link back to Discourse they would see the current content and authorship, with (given sufficient permissions) edit history view.
The same logic applies to wikis. They show up on Discourse under singular authorship but allowing others to write. Updates by other authors are not broadly attributed (unless you have sufficient permission to read the history). It’s not actually particularly meaningful whether that attribution is displayed by an avatar on the web view within Discourse or an activitypub actor associated with an activity; the end result is attribution presented to the human reader at the other end of one rendering pipeline or another.
1 Like
Hm not sure I agree. The end result of this will be two identical Notes in the Fediverse authored by different Actors, both of which will be still visible on multiple platforms. For a new person coming to that content for the first time they’ll see the same content authored by different people. Conversely, when you change an author in Discourse you essentially re-write history, for a new person coming to the content for the first time you just see the new author. There’s a difference there don’t you think?
I’m not sure I entirely understand. Are you saying that all edits to the wiki post, by any user, should be just treated as standard Update activities attributed to the original Actor (i.e. the person who posted it)?
Note that this is the subject of this PR, accompanied by explanatory notes.
4 Likes