Interoperability with MissKey

Sat, 17 Dec 2022 16:12:22 +0100

adminsforum@hubzilla.org

Interfed schrieb den folgenden Beitrag Sat, 17 Dec 2022 16:12:22 +0100

Interoperability with MissKey

There is a bug with #Misskey, which appears to be on #Hubzilla's side (maybe something about #NomadicIdeintity)
See this analyse: #^https://misskey.m544.net/notes/7185209c8f737cb0a36f1e6d

Thanks

show all 5 comments

Thu, 05 Jan 2023 21:29:54 +0100

Scott M. Stolz

scott@loves.tech

It looks like the ID refers to the copy of the conversation which is on ussr.win, but the specific comment (item) that URL refers to came from a user on hubzilla.eskimo.com.

Someone more technical than I could probably verify this, but I am guessing that Hubzilla reports where the comment actually came from (i.e. hubzilla.eskimo.com), rather than where a copy of the comment is located (i.e. ussr.win).

Also, the link given seems to point to a specific comment, rather than the start of the thread. That may be affecting things as well.

For reference:

This is the link to the whole conversation: #^https://ussr.win/link/7167676

This is the link to that specific comment: #^https://ussr.win/display/b64.aHR0cHM6Ly91c3NyLndpbi9pdGVtL2JjNjM2MDAzLWJiZmMtNDNhMi1iZTkwLTMxMzJiNmU0MmIyYw

And apparently the conversation was actually started on mastodon at: #^https://respublicae.eu/@mbompard/109519019431199836

Fri, 06 Jan 2023 21:15:37 +0100

Mike Macgirvin

mike@macgirvin.com

When we clone content, we intentionally do not change the message-id, as this is used in all messaging systems known to man to prevent duplicates. If we changed it, everybody (including nomadic platforms) would get a duplicate post from every clone. I've implemented nomadic content before, but it is completely incompatible with ActivityPub - so I haven't released this work.

The bug is invalid. Close it and let the Misskey devs work on real bugs.

If the Misskey user accepted connections with both the original account and the clone, they would have received the post from the location it was posted from originally - and it's OK if they toss the second. It's a duplicate. So this bug is invalid.

If they didn't accept one of the connections, there's nothing we can do about it. So, if they don't get some of your content as a result, that was their choice to make.

The only way this could be a valid bug is if the Misskey user was connected to both (or more) clones, and didn't receive the original from the site it was posted and hadn't blocked or filtered it. But this would be a completely different bug.

Fri, 06 Jan 2023 22:07:29 +0100

Mike Macgirvin

mike@macgirvin.com

Correction. So I just looked at the post referenced originally. In this case the Misskey user tried to manually import a Hubzilla post onto their system from the secondary copy by pasting it into the search bar. And they got a mismatch on the author id. The only thing they can do about it is import it from the original location. There is no written specification anywhere for importing posts manually. So I'm sympathetic, but this isn't a bug either. Not every link you paste into the search bar is going to result in an imported post. Possibly Misskey could check for this mismatch and automatically pull from the correct location (as they did discover the mismatch, so the solution is half implemented already), but that project isn't nomadic identity aware, so I doubt it is a priority for them to do so and I wouldn't blame them if they said it was too much trouble.

Sun, 08 Jan 2023 18:58:04 +0100

Malendur

malendur8944@hub.art3mis.de

Why not simply use something as rdf:seeAlso to link to the original location?

Mon, 16 Jan 2023 11:09:47 +0100

Nolan

nolan@ein-hub-von-vielen.de

No: I think the point is that Hubzilla need to list the specific clone as author.