As far as I can tell, this happens when a server sends Create activity directly to SocialHub, and also to NodeBB, which wraps it in Announce and also sends to SocialHub. I suspect that Create and Announce arrive roughly at the same time and some conflict occurs during the processing.
Note that one comment appears as federated but its copy is always local.
It sends me a token request with grant type client_credentials.
@angus Hello, can new topics be created here by mentioning a category in a post (from another server)?
It would work if:
The plugin doesnât (currently) allow topic creation from actors that arenât followed by the actor the Create activity (or equivalent) is sent to. I know that may seem restrictive compared with stream-based implementations, however forums are inherently more slow paced and controlled than stream-based stuff. That restriction may be modifiable by settings at some point.
Did you figure this out btw? The current implementation seems to be working well for folks authenticating their Mastodon accounts.
The next time this happens Iâll be ready to properly debug it, as Iâll have the raw JSON received (with timestamps). Iâll recreate the case like I did to debug the context issue.
Apparently client_credentials grant type is something new, I donât remember seeing it before in Mastodon docs.
Other Mastodon API clients use authorization_code grant type.
Is there a clear path from authorization_code to client_credentials? Does the former replace the latter? Was this something created within @mastodon or discussed with the larger community?
I donât know, here is what the doc says:
grant_type. Set equal to
authorization_codeifcodeis provided in order to gain user-level access. Otherwise, set equal toclient_credentialsto obtain app-level access only.
https://docs.joinmastodon.org/methods/oauth/#form-data-parameters
What I understand from Logging in with an account - Mastodon documentation is that the first time you authorize an app, youâre using client_credentials (AKA username and password), and then you can retrieve an OAuth authorization_code.
Regarding authorization, this is how the Discourse plugin implements the Mastodon OAuth API in a bit more detail:
Thank you! Iâll add support for the client_credentials flow at some point.
The problem with duplicated remote comments seems to be gone (I am writing this comment from my own server).
However, I discovered another issue with remote comments like this one: https://socialhub.activitypub.rocks/t/1b12-vs-guppe-groups/5032/13.
Its ActivityPub ID is
https://socialhub.activitypub.rocks/ap/object/07746fd71af9af4f0789f9e4798f33ec
and its attributedTo property has the value of
https://oisaur.com/users/renchap
meaning "actor from oisaur.com created object on socialhub.activitypub.rocks", which generally shouldn't be allowed (unless this actor is explicitly authorized to do so).
I think Discourse should show the original ActivityPub ID of the remote comment when user clicks on the "ActivityPub" button. This probably affects federated activities as well.
this is generally not an issue with the way the facts are being claimed. the issue is with identity and identity equivalence.
in other words, âobject on socialhub.activitypub.rocksâ is a re-serialization of âobject on oisaur.comâ. this is a link relation waiting to be captured. possibly you could claim an equivalence relation of some kind, or some concept of syndication could help.
authorization is a separate axis entirely and depends on the authorization scheme being devised. at minimum, you can use signatures as proof, or you can signal which prefixes you âownâ. authorization also depends on the identity scheme being used.
@silverpill@mitra.social wait, is it a remote comment?
Understandably, I could be confused by Discourse's UI, but @renchap@oisaur.com didn't compose that post, the local account on SocialHub did, because it's got a green AP logo.
Discourse seems to have combined the two accounts and is sending out the reply with the incorrect attributedTo. NodeBB would likely parse that note and see that NodeBB actually pulled that Note in perfectly fine.attributedTo does not match the signed actor, and drop it for security reasons. Let me confirm that...
Okay, now I am not sure. There is no valid webfinger response for renchap@socialhub... so perhaps there is no local SocialHub account.
I wonder why that post had a green AP logo then.
This may be my âfaultâ, I had a @renchap account here that was created from ActivityPub (using @renchap@oisaur.com), then I created an account on Discourse and asked the admins if I could grab the @renchap username.
I think they merged the 2 accounts, and probably it created some bug in Discourse where I now have a ârealâ @renchap SocialHub account, but tied to my external @renchap@oisaur.com AP account?
Yes, staged ActivityPub users have an invalid email address, so I had to change it and activate the account to perform the user merge. So I guess I might have hit a bug as a result. The other account was a regular one.
Hey guys, Iâll investigate exactly what happened here in a few days when I have the time.
This may be the culprit. I will investigate.
Iâd just note for future reference that if you want to associate an ActivityPub Actor with a Discourse user, the way to do that is in your profile.
The reason only Mastodon and Discourse Actors are supported currently is because you have to authenticate with remote platform hosting the Actor to claim it so each type of platform needs to be added individually (as each type uses different auth systems).
