So should I store user settings in plaintext on relays? Then everyone could see your settings. It would not be obvious to users that this is the case.

We could encrypt the data in the event. Then people could not see your settings anymore... but they could see WHEN your settings get changed, in realtime.

Finally, we could just store the settings on the server. But then the data is not exportable.

Thoughts?

I'm using Deno's built-in formatter, which is very nice and convenient because it mostly does what I want out of the box. I wish it could organize imports better, that's it.

I'm using Codium with the "Atom One Dark" theme, which makes the hideous VSCode editor look a bit more like the beautiful Atom editor that was put to rest last year.

I'm also using the Fira Code font for the nice ligatures. This is a must for me because it makes code so much easier to look at. https://github.com/tonsky/FiraCode

nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 check out my NIP-98 parser.

And they said TypeScript can't be beautiful.

There are scaling problems with the Fediverse. The more servers you federate with, the worse it gets. Nostr is no different. It's a fundamental issue of decentralized networks. And yet we're here chatting. I'm not concerned about it - it's FUD, when in actuality Nostr scaling is no worse than anything else, and in some ways it's better.

> 1 === 1

true

> 1 === 1 === 1

false

I understand why this happens, but it’s still interesting.

Yep. 👋 DMs don't work, though. It just goes into the void.

Ohh. Nah we don't need the extra complication of that. The problem I'm facing is related to the fact Nostr events want to be public.

That's exactly what Facebook is hoping for, and the reason they haven't pulled the trigger on federation.

Meta built an entire new ActivityPub server from the ground-up specifically to federate, and then decided not to. They don't need to actually federate, they just need the threat that they COULD federate. This is Art of War.

Elon knows what's right, but it conflicts with his mission to rule the world. This is a Cold War between Facebook and Twitter. It will last 20 years and nobody will drop the nuke. All we can hope for is a catalyst.

I agree. I was also experiencing some bugs like that.

My understanding is that their database has "posts" and "comments" in a separate table, more like Facebook rather than Twitter. They had to work around that to implement ActivityPub, figuring out which messages would be considered "posts" and which "replies", and then putting them through the proper pipeline to convert them into one or the other on their end. That would be complicated.

That exists: https://nostr.watch/relays/find

Ditto can import all relays from this API too:

deno task relays:sync https://api.nostr.watch/v1/online

Then they go into a big SQLite table (pic 1). The problem with this is that it’s centralized.

Instead, the “natural” way Ditto discovers new relays is by analyzing events, trying to find references to relays. If it finds one, it connects to it. (pic 2)

That can probably be abused, so in the future I’m planning to have a relay discovery flow where admins can review and manually approve any relays that have been discovered automatically: https://gitlab.com/soapbox-pub/ditto/-/issues/62

Indeed. I'm chatting with Nostr users every day through the bridge and it's working pretty well. It will only get better with Ditto. But Nostr clients need to do a better job about discovering relays automatically and using them to find content. Mostr only posts events to 3 relays, and very few clients deal with that appropriately.

No, that's only ever happened between minds.com users.

nostr:note1rv2sg2h2sdyy3hkyhncauthcaglvadtkm6agkpsx6uk2kvwh47tspe7qre

This is weirdly reminiscent of Monster Rancher for PS1:

>Although it is possible to acquire a monster in-game, the series is known for the ability to acquire new monsters using Compact Discs (CDs). Players can use any readable CD, and the game creates a monster using the CD's metadata.[6] Certain CDs would result in unique monsters: for example, Tecmo's Deception gives the player Ardebaran, a villain from that game,[7] and some Christmas music albums will give the player a monster of type "Santa".

https://en.wikipedia.org/wiki/Monster_Rancher_(video_game)#Gameplay

Maybe this idea is a catalyst for something else.

It's the entire purpose of this module in Pleroma: https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/transmogrifier.ex

I appreciate fiatjaf's wisdom that this is what leads to "protocol bloat", but this is the inevitable late stage of any decentralized protocol. You can't control what other people do, and if you want to be the best you have to handle all possible scenarios for your own self-preservation.

That is fascinating. https://github.com/simdjson/simdjson

If you're trying to get sub 100ms responses I guess you go out of your way to complicate things, but users are willing to wait a couple seconds for your shit to load as long as you give them a nice loading skeleton. You can get away with a lot if you do that.

Well, are you gonna put your money where your mouth is or what?

🤔

nostr:note1pe65yx8tesnt5phww5xr279vgmvq3u4p5dp84ad67fkem2p2jygqzazefl