hmm good point, maybe i should consider this - though since i do much selfhosting it just felt right

GM!

Been quite here, but for good reasons! We moved to our new house and baby 3 was born! ♥️

We went for a #homebirth and luckily found a midwife that supported us. But in the night everything went so fast that she did not arrive in time and my wife and me were on our own. She was so strong and brave and everything went smoothly 🐣

Now it's time to groove in to our new family structure and I love being at home for about a month.

10/10 would recommend homebirth if you feel like it. Though doing it alone was def not our plan, but of course it was that first night with snow and baby wanted to say hello quite fast 😃

So proud of my wife ♥️

Five flights, one boat ride and two days later, I’m back in my island 😍

It’s that time of year where I meet my brother in the city to honor our father by continuing the tradition of getting close shaves the day before Thanksgiving.

Cherish every moment with your loved ones.

Honor your mother and father.

In any case: I’m glad (and surprised!) that I’m not the only person in the world using it! 😅

Hi there, IMO it is likely a provider issue. I just tried it myself and it worked. Were they failing 100% of the time or just occasionally?

I have lived under the realization that people don’t care about other people because they are mostly focused on themselves.

What i have been discounting is there is a large asymmetrical opportunity given this fact. just by trying to care and help other people, you will be doing what the majority of people don’t do since they are too busy dealing with their own issues.

Once you have your shit figured out physically, mentally and financially, this seems like the thing you should spend time on to have large positive impact.

I suspect empathic people already do this naturally, but as an antisocial autist i had to come to this conclusion via logic.

I'm running Core 30.0. Feels good man.

Cry harder useful idiot statist cucks.

sounds like another wasteful project

rektbot9000.albylabs.com

As a young Thälmann Pioneer in the GDR's communist youth organization, I faced my share of challenges. I dreaded having to march in uniform. From my bedroom window, I enjoyed an unobstructed view of the Wartburg—the castle of utmost historical significance to the Germans, where Martin Luther once sought refuge from the Holy Inquisition, an institution that disapproved of anyone advocating for separation of church and state. Today, I support the idea of separating state and money. In short, I just refuse to march to someone else's beat!

#bitcoin 🧡

I've found out I can set a nostr username with my nostr provider iris (in the settings), but log-in with my username (nostr address nip5) generates an error message

TypeError: Xt.nip46 is undefined

# The case against edits

Direct edits are a centralizing force on Nostr, a slippery slope that should not be accepted.

Edits are fine in other, more specialized event kinds, but the `kind:1` space shouldn't be compromised with such a push towards centralization, because [`kind:1` is the public square of Nostr, where all focus should be on decentralization and censorship-resistance](cd8ce2b7).

- _Why?_

Edits introduce too much complexity. If edits are widespread, all clients now have to download dozens of extra events at the same time while users are browsing a big feed of notes which are already coming from dozens of different relays using complicated outbox-model-based querying, then for each event they have to open yet another subscription to these relays -- or perform some other complicated batching of subscriptions which then requires more complexity on the event handling side and then when associating these edits with the original events. I can only imagine this will hurt apps performance, but it definitely raises the barrier to entry and thus necessarily decreases Nostr decentralization.

Some clients may be implemneted in way such that they download tons of events and then store them in a local databases, from which they then construct the feed that users see. Such clients may make edits potentially easier to deal with -- but this is hardly an answer to the point above, since such clients are already more complex to implement in the first place.

- _What do you have against complex clients?_

The point is not to say that all clients should be simple, but that it should be simple to write a client -- or at least as simple as physically possible.

You may not be thinking about it, but if you believe in the promise of Nostr then we should expect to see Nostr feeds in many other contexts other than on a big super app in a phone -- we should see Nostr notes being referenced from and injected in unrelated webpages, unrelated apps, hardware devices, comment sections and so on. All these micro-clients will have to implement some complicated edit-fetching logic now?

- _But aren't we already fetching likes and zaps and other things, why not fetch edits too?_

Likes, zaps and other similar things are optional. It's perfectly fine to use Nostr without seeing likes and/or zaps -- and, believe me, it does happen quite a lot. The point is basically that likes or zaps don't affect the content of the main post at all, while edits do.

- _But edits are optional!_

No, they are not optional. If edits become widespread they necessarily become mandatory. Any client that doesn't implement edits will be displaying false information to its users and their experience will be completely broken.

- _That's fine, as people will just move to clients that support edits!_

Exactly, that is what I expect to happen too, and this is why I am saying edits are a centralizing force that we should be fighting against, not embracing.

If you understand that edits are a centralizing force, then you must automatically agree that they aren't a desirable feature, given that if you are reading this now, with Nostr being so small, there is a 100% chance you care about decentralization and you're not just some kind of lazy influencer that is only doing this for money.

- _All other social networks support editing!_

This is not true at all. Bluesky has 10x more users than Nostr and doesn't support edits. Instagram doesn't support editing pictures after they're posted, and doesn't support editing comments. Tiktok doesn't support editing videos or comments after they're posted. YouTube doesn't support editing videos after they're posted. Most famously, email, the most widely used and widespread "social app" out there, does not support edits of any kind. Twitter didn't support edits for the first 15 years of its life, and, although some people complained, it didn't hurt the platform at all -- arguably it benefitted it.

If edits are such a straightforward feature to add that won't hurt performance, that won't introduce complexity, and also that is such an essential feature users could never live without them, then why don't these centralized platforms have edits on everything already? There must be something there.

- _Eventually someone will implement edits anyway, so why bother to oppose edits now?_

Once Nostr becomes big enough, maybe it will be already shielded from such centralizing forces by its sheer volume of users and quantity of clients, maybe not, we will see. All I'm saying is that we shouldn't just push for bad things now just because of a potential future in which they might come.

- _The market will decide what is better._

The market has decided for Facebook, Instagram, Twitter and TikTok. If we were to follow what the market had decided we wouldn't be here, and you wouldn't be reading this post.

- _OK, you have convinced me, edits are not good for the protocol. But what do we do about the users who just want to fix their typos?_

There are many ways. The annotations spec, for example, provides a simple way to append things to a note without being a full-blown edit, and they fall back gracefully to normal replies in clients that don't implement the full annotations spec.

Eventually we could have annotations that are expressed in form of simple (human-readable?) diffs that can be applied directly to the post, but fall back, again, to comments.

Besides these, a very simple idea that wasn't tried yet on Nostr yet is the idea that has been tried for emails and seems to work very well: delaying a post after the "submit" button is clicked and giving the user the opportunity to cancel and edit it again before it is actually posted.

Ultimately, if edits are so necessary, then maybe we could come up with a way to implement edits that is truly optional and falls back cleanly for clients that don't support them directly and don't hurt the protocol very much. Let's think about it and not rush towards defeat.