Oddbean

In the current Nostr ecosystem, user profiles are often overwritten by different applications that maintain their own versions. This lack of synchronization and consistency across apps can lead to outdated or incorrect profile information. A unified, versioned profile system is necessary to ensure that users can maintain a single, authoritative profile that is synced across all devices, apps, and relays, while still allowing for personalization and extensions. NIP Proposal: Simple Nostr Profile System https://github.com/sandy-mount/sandymount/wiki/nostr_profiles

I agree, the problem is real. Good spec! I only disagree on the git part. It's too complicated for non tech people. Also, do I really want to rollback to a previous version? When I want to change something, I just update my profile

Good point. I could change it to something else. But what other way can you do versioning? The root problem that I would like to address is when your profile gets overwritten. What do you do then as a user?

You could probably just forget versioning. If your profile is hosted on a webserver, like on .well-known page, you know it's the latest version. So if your profile is overwritten on some relays by a client, you still can rely on the .well-known version and publish this version. Do I understand correctly?

Ah, I see. That could work. But then it seems it would be a more manual process of overwriting. So each workflow would involve some UX complexity. Good thought, I'll bear it in mind. I'll loosen the git part to a SHOULD for now, as there can be more than one approach.

That's the idea, to have it automagically in the .well-known, but as an opt-in not as a mandatory requirement. There are clients who just absolutely refuse to update profiles, or worse yet wipes out your profile and it drives me nuts. took well over a month for njump to update

😅No. It is not trivial to reproduce about anything in nostr given all the permutations of app interactions - 1,000 nostr apps is approaching half a million app pairs. This is why I ask. If we have this info it becomes possible to debug. In the mid to long run we have @sandwich @Arjen and others working on various angles on CI to where we automate the QA.

I’m the nostrability product janitor. nostrability repo contains negative interoperability issues like the one you run into. There are many of these. If we dont systematically catalogue, these wont be fixed. If these are not fixed, the average normie big tech user who expects things to “just work” in app, and across apps will drop off. Specifically the “hop” between apps is a user friction point. If the hop friction is too high, users wont bother with using the strength of nostr - many apps, and nostr will recede into obscurity. Now that I write this, there may be perpetually unmaintained apps. Maybe its worthwhile to catalog these to a high friction list to warn devs, and end users of potential for a crap experience.

I cannot guarantee human action of others, and I have been bringing up to the attention of devs various issues their app is involved with. Thus far, many devs have been receptive and worked together with their counterparties to resolve multi-app bugs, negative UX behaviors. https://image.nostr.build/6941ccc7bd3e54e2c05958756ff1818fd82ae550e8ad36dda5975cde9453cf0f.jpg https://image.nostr.build/a953542b1f42f250d8e3b0f354e8f3f0fe69d50b5f1ad36128f05f2d1835e685.jpg https://image.nostr.build/03c8f9f9ccb3059f8866d2ce779ad444b40430f7fff06dce00574c8bcc4cde6f.jpg

Yes that is I think an ideal way of doing it. Except I would need to write more code and create more tooling to get to a full solution. Using git as an intermediate step (which I've now made optional), it is easier to prototype, and let the user trying, work on the UX etc. A next version could remove the git dependency all together.

Bitcoin nodes use proof of work to ensure that our nodes can all agree on the current state of the Blockchain. However, I can't afford to shit post on those nodes because the consensus mechanism forces all nodes to store the same thing - which doesn't scale to many posts. Nostr relays (and git remotes) don't have such a consensus requirements, which means that different relays may give you different profiles pictures. This seems annoying, but I also don't want all relays to agree which of my content to store, because in most cases they would agree that it's too costly to store any of my content.

These are valid arguments, but we can get a bit more creative here, and put our minds in problem-solving mode. There's multiple arguments presented here, so I'll just tackle one. And that is, "its too expensive". It's only expensive if you lose the base layer. It would cost you about 300 sats to timestamp your profile. That might be a worthwhile cost for those that value their profile. Furthermore on higher layers, you can get the cost down to something nearer to 10 sats, or even 1 sat. All be it with some security trade-offs, which the vast majority of end users wont notice, especially if the UX hides it. Even better, using testnet, you can get the cost down to zero, and the system would still work. Bear in mind, im just using the blockchain argument here, and not even talking about other options. Consistent data is useful for all sorts of things, and we can get the cost down to very low levels. Inconsistent data is problematic, and I'm not sure how easy it is to argue that it's a feature not a bug. It might be in some cases, but in another, or lot of cases, consistent data is desirable.

Indeed, timestamps are really useful in nostr notes. I agree that inconsistency is often undesirable, though I'm hesitant about concluding that relays should coordinate. It's my nostr client's job to ensure that the content is consistent across all the relays that I use. Perhaps I should be using fewer relays if I'm unable to maintain sufficient consistency across all my relays. It's enough to have just one relay with the outbox model 😀 I realize the UX suffers from having all the business logic in the client, but where do we draw the line between Twitter and nostr if our relays keep getting smarter?

Short answer: relays dont get smarter, clients do. You provide the proof in a tag, and it can be verified by the cllient. The client knows when a profile is the latest, and when it is stale, that's about it. This also opens the door for other use cases, other than profiles.

Too many reasons to count. Firstly the relay is in a state of willful neglect, so users see problems all the time. Secondly relays by their very nature are not designed to *store* notes, just to *relay* them. They are GOOD at relaying notes, but not good at storing notes. Relaying is more resource intensive than storing, because you have to be always on. Added to that you need a caching layer to scale, which nostr didnt start with, and still hasnt developed. Also nostr never had an architecture, it was just a quick thing put together that just about worked, it was never intended to scale, it was intended as a proof of concept. But the critical thing, is that for scaling you need a uniform interface ie scaling architecture, and it has to be pretty good. Getting people to agree on such a thing is very hard, especially with the current state of NIP centralization. Best that we can hope for is that someone will invest in hardware, but we've still not seen that yet, despite large donations. tl;dr nostr still has a chance of scaling, but it would take some work and some luck. That work is not being done, so, we would need a game changing event.

I can do it because I love Digit for being smarter than me Jack can't do it because he has deep rooted psychological issues with people being smarter than him, as shown by his past social media client, Twitter

I knew her online for a couple years but we were only close for a short time. I never got to learn much about her. She had disappeared another time in the past and come back but this time is different. I was always trying to get her to talk to me again to clear up lies others told her about me that made her stop talking to me in the first place. Before she left she made me stop trying to talk to her by threatening to disappear if I tried talking to her again, so I left her alone for a while, but then she started posting about suicide a lot and nobody was trying to help her so I didn't have any choice but to try talking to her again. She didn't mention faking her death so the rumors of her faking her death or killing herself make me even more terrified. I hope all that happened is she disappeared to scare me like she threatened to do, and added faking her death on top of it. I'm scared the threat could have been reverse psychology designed to distract me from her killing herself. I wrote a longer post about all this here nostr:naddr1qvzqqqr4gupzqamkcvk5k8g730e2j6atadp6mxk7z4aaxc7cnwrlkclx79z4tzygqq9ysmmhf9e5g6t8d96q2ftu5e