Untitled attachment

Notices where this attachment appears

1. Embed this notice
   Alex Gleason (alex@gleasonator.com)'s status on Monday, 26-Jun-2023 01:21:13 JST Alex Gleason

   in reply to
   @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d @de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645 The original object has its own globally unique ID. Eg event.id on Nostr, object.id in ActivityPub.
   
   So you expose that ID to the bridged network, and implementations can combine objects that share the same proxy ID.
   
   For AP objects bridged to Nostr, it could look like:
   
   ["proxy", "activitypub", "https://gleasonator.com/objects/123"]
   
   Clients could combine events with the same proxy ID.
   
   There are obviously problems with trust (among other issues). But I think it will be necessary to solve this problem.
2. Embed this notice
   Alex Gleason (alex@gleasonator.com)'s status on Wednesday, 10-May-2023 03:11:41 JST Alex Gleason
   @76c71aae3a491f1d9eec47cba17e229cda4113a0bbb6e6ae1776d7643e29cafa @eris @strypey @5be6446aa8a31c11b3b453bf8dafc9b346ff328d1fa11a0fa02a1e6461f6a9b1 > a way to have multiple mostr instances.
   
   So, here's my recent discovery on that: https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-fffd.md
   
   Currently Mostr publishes kind 1 notes. It contains a tag linking back to the original ActivityPub object like:
   
   ["mostr", "https://gleasonator.com/objects/123"]
   
   Technically this is enough for Nostr clients to consolidate multiple ActivityPub events into one. We'd also want relays to let us filter by this tag.
   
   However I'm a big fan of the "proxy objects" concept, which aims to be a way of representing _any_ object on a different decentralized network.
   
   On Nostr we could generalize the tag so it would work with ActivityPub, Bluesky, etc. Clients would have to support it (by treating all events with the same tag as one), and relays should support filtering by the proxy ID for the best UX.
   
   On the ActivityPub side, servers can use the FEP.
   
   The only problem is that if we canonicalize a way to represent people on other networks using any keypair, there needs to be a way to confirm the object isn't forged, which would necessarily require all software to implement all protocols... so that's where I'm stuck.