angus:Then authenticates a user using OAuthYes, but what authentication flow does it use?
-
angus:
Then authenticates a user using OAuth
Yes, but what authentication flow does it use? My verification fails at
/oauth/tokencall.---
On the topic of federated categories -- the problem with duplicated comments from other Fediverse servers persists: https://socialhub.activitypub.rocks/t/wordpress-follow-failure/4850/2
-
angus:
Then authenticates a user using OAuth
Yes, but what authentication flow does it use? My verification fails at
/oauth/tokencall.---
On the topic of federated categories -- the problem with duplicated comments from other Fediverse servers persists: https://socialhub.activitypub.rocks/t/wordpress-follow-failure/4850/2
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.
-
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 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/07746fd71af9af4f0789f9e4798f33ecand its
attributedToproperty has the value ofhttps://oisaur.com/users/renchapmeaning "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.
-
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/07746fd71af9af4f0789f9e4798f33ecand its
attributedToproperty has the value ofhttps://oisaur.com/users/renchapmeaning "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.
@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 thatattributedTodoes 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.
