Goofed Home

@Edent It should work. But of course, there is a possibility of some popular implementation not being able to handle it.

@Edent embrace the diversity. 😜

@Edent FEP-7628 is the only accurate spec. Move activity should be delivered to followers and have an ID (just like every other activity).

SWICG document is incomplete. SocialDocs website appears to be AI-generated.

@julian I can read the outbox and activities 👍

There is a minor problem with Like activities, which don't have a to field (this means nobody should be able to see them).

And while we're at it: when NodeBB sends a signed GET request, does it add a Digest header? I see warnings in my log due to invalid header value.

@django @hongminhee

Hello Fediverse,

I would like to receive some feedback on this idea I have been kicking around, and see if others might be interested in contributing. I have a basic prototype that proves out most of the technology, but not much beyond that.

The basic general description is an Iroh based identity layer for the open web. This platform would serve three primary functions:

1. Preserve and consolidate social graph data in an encrypted local storage vault, allowing for import, display, and management of media and posts from both walled garden platforms and open platforms.
   
2. A “universal translator” across open platforms, allowing for seamless connection between activitypub, AT protocol, and rss subscriptions. You are able to link mastodon, Lemmy, pixelfed, loops, and blusky accounts and your legacy social media imports can also generate RSS subscription feeds for your previous Instagram or YouTube (among other platforms) subscriptions, with all this content showing up in a single filterable fleed.
3. Identities can be linked to any unique URL, using an umbrella DID. That URL can be any location the user chooses, including an indieweb page, a spacehey.com profile, or any other site the user controls and is able to host the corresponding DID document for cross platform identification.

There are many more details and features I have in mind that this architecture could facilitate, but this is the overarching basics of what I had in mind. I am very open to critique or analysis of this architecture, potential issues and limitations, as well as ideas for modification.

I would also welcome collaborators and contributors if there is interest, and I can open up the project for whoever may be interested. Let me know!

Forte and tootik use FEP-ef61 with server-managed keys. I am working on an application where keys are stored on the client side: minimitra. This is probably closer to your idea.

Do you want to use iroh for transport, or for identity?

Iroh was more of the p2p transport layer, but it is what facilitates the authentication through DID to the local vault. The work you linked is very relevant and will be definitely be of use!