Sam Goto

Yeah, that seems like one of the reasons why they might thrive on bluesky more than ever before, because they can set up their own atproto app with their own moderation tools?

FWIW, I just sent this activateRequest account to refresh the association between my did and my handle without going over deactivation before ...

bsky.app/profile/thre...

I'm wondering if it would work if I pointed my DNS TXT record to a did:web address to my pds ... any chance that would work as an alternative to serving the did doc in my APEX domain?

Wow, that's such an interesting experience ... I don't think I have run into that trend on my history of using social networks ... orkut.com > reader.google.com > facebook.com > twitter.com > instagram.com > tiktok.com I don't think I ran into that trend you are describing in those places ...

@threddyrex.org any issue with caching so far?

@thisismissem.social any specific part of the stack that does caching that you are concerned about?

It is really exciting the amount of agency that atproto gives to the community!

that's good to know ... i dont think my domain ever had a did:web, because it was only used as a DNS TXT record pointing to a did:plc that the bluesky team created and hosted ... so ... i think I'm safe?

Or is it possible to create a bluesky account did:web?

Why am I surprised that this even exists ... of course ...

omg, there is even an onlyfans here! insane!

same here :) had to increase limits today :)

Coupling my entire social present with my ability to manage my own private keys sounds impractical to me ... I don't trust anyone to manage my keys (if so, what's the point? Id rather go back to RSS).

I get the point that DNS is centralized, but I think that might be a better trade off to me ...

At the core, I think I want you all to follow @sgo.to, not a did ... That is, I want to be able to have a point of indirection that I can move everything ...

I don't want to manage a private key, that doesn't seem like a sustainable self hosting situation.

I cant even self host my own passwords...

I might reboot this account again, because I think I like did:web better than did:plc ...

I'll take a look at this next week, but heads up that I might rebootstrap :)

These are pretty ephemeral? I could just require it to be reissued?

Ah, you are referring to the root of the Merkle tree? As long as the root vouches for the whole tree, every leaf is also trusted by the root? And if the did:web did doc points to the root, everything else can stay the same?

"trust is rooted in your did doc" I think that makes sense to me ... But then, doesn't that require me to "add all public keys that I feel signed anything in my repo to my did doc"?

What do you mean by "added space to my profile"? You mean you added "both the old and the new key to your did doc"?

But before I can commit to my repo with a new keypair, don't I need my prior keypair?

Or is the entire trust based on "keys that are announced in my did doc"?

Ah, so I could just make a commit that I added a new key that is associated with my @handle and keep all of the old commits and also say that all of those old commits with the old key are still associated with my @handle?

When you say "you can always resign your data again", wouldn't you lose the engagement with your data? E.g. when someone likes/replies/comments of your data, when you resign it, wouldn't that be lost?

@fry69.dev I think this is where things break: every old posts id lose, I think.

I could resign all old posts with the new private key, but Im guessing I would lose all of the associations (e.g. comments, replies, etc?) from other people?

And if I threw away the private key and announced a new public one, would the relays then disassociate my old posts with my handle?

What's that last step? Why is it needed? And what would the commit be?

If so, I might need to migrate onto another bsky profile, because I have no interest in managing public/private keys, and don't mind at all relying on DNS for my @sgo.to handle* :)

* which, i'm guessing, with did:plc I'm still relying on DNS to point my @sgo.to handle to the right did:plc?

Any chance anyone following me can confirm or refute this?

If I move my PDS to use a did:web, can I entirely remove the need to manage public/private keys (e.g. I could just generate a dynamically generated public/private key for repo commits upon startup)?

Does that sound right?

Would I be able to just automatically generate a new public/private key always dynamically (say, at server startup) and use it? Are the relays going to be happy about it?

I would love to not to have to manage keys at all (and I don't mind my @sgo.to handle to be tied to DNS).

I never ran into bots or fakes that much in other places like twitter, orkut, facebook and so on ... have you?

But for your repository commits, don't you need to sign the commits with your private key?

Are you sure that (we don't need rotation keys with did web) is the case?

With the exception of LinkedIn and recruiters, but maybe thats more spam than engagement :)