Federated SocialHub Categories

[silverpill]

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.

[silverpill]

@angus

grant_type: "authorization_code",

It sends me a token request with grant type client_credentials.

[silverpill]

@angus Hello, can new topics be created here by mentioning a category in a post (from another server)?

[angus]

@silverpill

can new topics be created here by mentioning a category in a post (from another server)?

It would work if:

• the mention led to the other server posting to this server; and
• the actor doing the mentioning was being followed by an actor on this server.

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.

[angus]

@silverpill

It sends me a token request with grant type client_credentials.

Did you figure this out btw? The current implementation seems to be working well for folks authenticating their Mastodon accounts.

[angus]

@angus

@silverpill

On the topic of federated categories – the problem with duplicated comments from other Fediverse servers persists: WordPress follow failure - #2 by pfefferle1

It’s not clear to me this is a Discourse bug yet. We’ll know more once we merge object JSON log viewing in the admin panel and I can see exactly what SocialHub is receiving and sending in those scenarios. If those Notes are replicated on other services with different ids Discourse would treat them as different Notes.

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.

A single post is somehow creating multiple topics with no replies

@devnull @how @trwnh Ok, I finally had the time to recreate this case in a spec. The reason this happened is because: Discourse was unable to resolve a Conversation type for context. The error thrown in 1 was too nested to properly roll back the relevant transactions. This will address the immediate issue @devnull I haven’t been keeping up with the latest on context / collections etc. Could you briefly explain the thinking behind using “Conversation” instead of “OrderedCollection” in c…

[silverpill]

@angus

Did you figure this out btw? The current implementation seems to be working well for folks authenticating their Mastodon accounts.

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.

[how]

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?

[silverpill]

I don’t know, here is what the doc says:

grant_type. Set equal to authorization_code if code is provided in order to gain user-level access. Otherwise, set equal to client_credentials to obtain app-level access only.

https://docs.joinmastodon.org/methods/oauth/#form-data-parameters

[how]

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.

[angus]

Regarding authorization, this is how the Discourse plugin implements the Mastodon OAuth API in a bit more detail:

[silverpill]

Thank you! I’ll add support for the client_credentials flow at some point.

[silverpill1]

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.

[trwnh]

@silverpill1

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).

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.

[julian]

@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 attributedTo does not match the signed actor, and drop it for security reasons. Let me confirm that... NodeBB actually pulled that Note in perfectly fine.

[julian]

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.

[renchap]

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?

[how]

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.

[silverpill1]

@julian @angus It might be a post made after remote login via OAuth

[angus]

Hey guys, I’ll investigate exactly what happened here in a few days when I have the time.

@renchap

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?

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).