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.


This looks interesting!

nostr:nevent1qqsgl7u4h88qqwwasgq5f482ag4ym5q0msw447vfqj90qvkhjf8jjpcpz9mhxue69uhkummnw3ezuamfdejj7q3qmelv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsxpqqqqqqzpxxpjf


Normie end users will not set up a well known pointer. This only works if handled automagically (e.g. onboarding app adds well known on behalf of the user).


Just use Bitcoin if you want consensus. Nostr is scalable because it doesn't come with guarantees...


Doesnt make much sense to me.  Nostr was not scalable from the get-go, having robust profile is the start of a scalable arch.


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


Can you tell me which clients give you trouble with profile updates?


Added placeholder: https://github.com/nostrability/nostrability/issues/111


Flockstr, njump, if i find more i will keep u posted


Do you suspect cloudflare/cache?


No, because njump persisted for weeks and flockstr would  not update after i edited and pushed.


What app are you changing your profile with?

What app are you using yo verify changes?


changed with flockstr, didn't update, still isn't updated

changed with primal; it updates

changes take a really super long time to propagate on njump


flockstr also has this annoying habit of autoplaying ancient vids i posted almost a year ago when i visit my profile.


Which app(s) are you using to verify the change went through?


satellite.earth, nostrudel and primal


Are you QA King?


😅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 nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx nostr:npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr and others working on various angles on CI to where we automate the QA.


I know that. I was just tryin to figure out why you wanted
to chase this so hard when its not clear to me some
Of these apps are maintained or not


Btw its an honor to bestow “QA king” if you’d like the title 😅


Wikifreedia


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?


Use the id of the event as a version control. It changes everytime you update your profile


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.


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.


Wow neat!
Apologies for my premature comments and thanks for explaining 😀


why isn't nostr scalable?


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.


The game changing event is someone like me surviving long enough to design the real nostr


Or Jack making an awesome client.


Nah, he's nowhere near capable of making a good client, let alone an awesome one


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’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.


No titles, just want nostr to win, and make my ikigai.


#yestr


Per fan’s request.


njump actually updates now?


It's been slowly updating for a while

nostr.at still doesn't


Fan as in fanquake?


This is a good strategy for public service.  But can be difficult
If the devs who are targets are not paying attention


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 because they are full time paid by grants and have lots of free time. Good for them. I am not so if i get spammed, all you will likely get is no response for a long time😅


I hear you.

There are quite a few devs and other contributors who are active, and are not sponsored


what is Digit?


My favorite musician. She sent me some science book pdfs


can I find her music online?


Here's the one song she sent me, I don't know if she ever posted any to the public

https://audio.nostr.build/808960a3289a3196a8b371c2239d6925357b9a41183925f9882ee2897df313d3.mp3


Oh  I meant per Dan”s request. nostr:npub1dgpt04w4c88wc0g262xaw8zvlm4mvwtmjhl0tn2sxtyjywsn6q4qt8ka3a


I am a fan of both their work! good observation Hodl


thank you for sharing, I wonder what Digit thinks of Nostr


I hope she's safe and she'll find nostr someday and enjoy it


sorry, I just read your profile description. for how long have you known her before she disappeared?


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