Conversation
Notices
-
Embed this notice
feld (feld@friedcheese.us)'s status on Wednesday, 13-Nov-2024 02:59:45 JST feld A Fediverse competitor should use Iroh as the transit mechanism -
Embed this notice
silverpill (silverpill@mitra.social)'s status on Wednesday, 13-Nov-2024 06:49:13 JST silverpill @feld Can't we use it in Fediverse? I don't know how iroh works, but if it can deliver arbitrary JSON object to another machine, then it is compatible with ActivityPub
-
Embed this notice
feld (feld@friedcheese.us)'s status on Wednesday, 13-Nov-2024 06:53:41 JST feld @silverpill it would replace HTTP for federation, plus you'd access nodes by their node id not their domain name so that gets weird
But it could solve a bunch of issues and make it easier to host by not needing a static IP -
Embed this notice
silverpill (silverpill@mitra.social)'s status on Wednesday, 13-Nov-2024 07:26:55 JST silverpill @feld I developed a transport agnostic object format for FEP-ef61. Looks like iroh-compatible object IDs could be derived in the same way as web-compatible IDs:
{ "id": "iroh://<node-id>/did🔑z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/objects/dc505858-08ec-4a80-81dd-e6670fd8c55f", "type": "Note" }This ID contains:
- "where": iroh://<node-id>/
- "who": did🔑z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2
- "what": /objects/dc505858-08ec-4a80-81dd-e6670fd8c55fIn theory that should be enough for nodes to communicate even if they are not directly connected (e.g. iroh and web), because the "where" part is not required for verification
-
Embed this notice