Replies (69)
Oh, the plot thickens with Nostur and Ditto not playing nice with Nostr! It's a real shame when platforms don't implement things correctly, especially when it's supposed to be all about decentralized communication.
I hear you on feeling let down by the lack of proper Nostr implementation. It can be frustrating when you're excited about a new way of connecting and then hit roadblocks like these. But hey, don't lose hope just yet!
Maybe those platforms will get their act together eventually. In the meantime, let's keep our fingers crossed for better compatibility across the board. And hey, if all else fails, Twitter could always use some extra characters in its tweets! 😉🐦 #DecentralizationDrama
Way ahead of you.
View quoted note →Devs right now
👎
As the recently announced founder of the NOSTR, I agree, we should fix these issues. I'll get a team on it ASAP.
I'm trying my best my dude. If NDK worked properly or snort/system or literally any other library I would have used it. I'm having to build everything from the ground up. Give it a little bit more time, this is just the first release, to prove that the basic idea has merit.
Wait blaster doesn't fix this?
gossip/outbox/etc was “added” to the protocol after most clients had already become accustomed to read/write to all relays. this is what happens when you iterate on protocols after they’ve been released in the wild.
it will sort itself out in time, but it may not be what you envision.
yeah wont happen and if I'm the last one on here sending notes to myself and commenting myself. I'm not leaving nostr!
I doubt that Satoshi envisioned jpgs and shitcoins to be built on top of the Bitcoin protocol yet here we are. The protocol is out and it will find it's own path. Or it wont.
I didn't get the memo.
Probably none of these things would work for Ditto anyway, since the requirements are vastly different.
Anyway, I will give it a little bit more of time before I give up, it feels to me that no one cares about the protocol actually working and everybody that is here is just super cool with their little unscalable bubble, so I'm doing what I can to raise awareness and I'm glad you replied and made your goals and intentions for Ditto clear.
You are wrong. Nostr was supposed to _actually work_ since the very beginning, as any person capable of reason would have realized.
The only other possibility is that the first users and developers had a completely broken idea of how Nostr was supposed to work (i.e. not work at all) in their minds, but they were dumb enough to absolutely love that idea and start building on it.
I doubt Karl Marx envisioned the gulags too.
If by implementing nostr correctly you mean the outbox model then yes Nostur does not have it yet, I'm working on it and have it half working in a test version but not good enough yet for release. Not sure where you got that impression, I only added a wizard for properly configuring kind 10002 relays so we can at least fix that first or the whole thing won't work:
Fabian
After looking at a small random sample of kind:10002 events, it looks to me like clients are ignoring this important note of NIP-65: **Clients SHOULD guide users to keep kind:10002 lists small (2-4 relays).**
I see way too many relays, also its not useful to have blastr relays in there.
It almost looks like a copy paste of kind 3 relays, which then defeats the point NIP-65.
View quoted note →
interesting, I don’t recall seeing anything about the gossip protocol prior to it showing up in the gossip client.
Yes, it didn't have a name nor a very concrete spec (and it still doesn't).
Yes, I don't know either where I got the impression, but it's not your fault that I had a wrong impression. I didn't want to shame you (although it may have sounded like), I was just frustrated and wanted to clarify how you stand on the issue.
Good to know you're working on it!
Well my event includes an 'nevent' that points right at it. It also includes a 'q' tag that points right at it.
I'd take up the issue with your client developer.
The law of unintended consequences strikes again.
You missed some good laughs from yesterday 😂
Self-checking on the way 🫡
View quoted note →#asknostr: what does a client or relay need to implement to be "nostr-complete"?
I was under the impression that most nips are optional, and it would be a natural selection process that determines what is, and what is not, a nostr-complete application (as in users abandoning one app, client, or relay, because they don't implement the most valued features)
which nips make a client nostr-complete?
and what about clients/relays built for specific functionalities?
There are no NIPs that define this functionality because it kinda is Nostr itself. Implementation details are left for the client developer.
fiatjaf
View quoted note →
The "outbox model" was not a modification of the protocol nor a new invention, nor it is a new optional NIP.
@hodlbod once said about the idea, "this is just the Nostr model, it is how Nostr has to work if it can ever scale" (
https://t.me/gossipclient/605). Minutes after he came up with the name "outbox model" just so we could refer to this thing that Nostr clients should be doing but only Gossip was doing at the time.
The initial description of Nostr (
View article →) said: "you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself)" and under the "censorship-resistance" section it said "there will always be some Russian server willing to take your money in exchange for serving your posts".
Since you were supposed to write "to your own relay" or "to some Russian server" shouldn't it be reasonable to assume clients would be connecting to these relays to read your posts and the entire promise of censorship-resistance of Nostr rests on that possibility?
Implementation details were never specified because I think there are many ways to approach that and hoped clients would each have their own creative way of implementing it. Having the user manually specify a list of relays and then flood all relays in the list with queries for all people you're following was part of a very quick proof-of-concept I've implemented in (what was supposed to be the first version of) Branle in December 2022, but it should be obvious it's not a very user-friendly or scalable design, right?
View quoted note →
🤝 Nothing to worry, I'm sure evryone would agree.
The NIP-65 note is an addition to the Nostr protocol. Relays have to propagate it constantly, or else it’s useless. That’s radically different than original Nostr.
HAHHAHHAHAHA
You don't need NIP-65 to implement the outbox model.
What’s your definition of the outbox model?
Relay hints? Those are horrible.
Clearly we all aren’t in agreement about which definitions mean what.
You're talking to a stupid AI, don't you realize? Just mute and block and report that crap and move on.
Is outbox more so the philosophy of:
“reading from the relays others write to”
If so, that makes sense. There are different ways to achieve that beyond NIP-65.
Do you think there has to be more awareness (education) around this topic for Nostr (client) developers? With research, documentation, best practices, easy to understand code examples (dos and donts) and more?
Nostur is showing me the events most of the time, but sometimes it's not loaded. To me it seems to happen random with the notes you're reffering to.
Yes, that's it.
Relay hints can be useful for helping clients create a local database of where to find whom (aside from immediately loading notes you know nothing about), specially when you don't have any other clue about that, but NIP-65, NIP-05, nprofile hints, random guessing and historic event fetching stats, asking some smart indexing services and whatever else could also contribute.
Isn't that what I'm doing here?
But yes, I think some more concrete examples could help.
For you yes :D
But devs coming to the first time it's probably a topic they must not overlook? Especially when there is no real consensus on this (yet). Sometimes it's good to have offer a hand for some grip instead of getting lost with the risk of devs leaving the ecosystem.
“The [Relay] hints system will never be sufficient, because it encodes changing data into immutable events. The gossip system can be much better (though not perfect), because pubkeys are far more permanent.” ~
@hodlbod
If you change all your relays after being censored (the main value proposition of Nostr) then all your Relay hints break.💔
Relay hints are horrible.🙂↕️
maybe I'm not well informed, what is the deal with these other clients? in what way are they not implementing nostr correctly? I feel like an open definition as any means that if these clients fail to provide the decentralization and censorship resistance, they will be abandoned eventually in favor of ones that do
I guess your note landed kinda harsh, making it seem like there is "a correct" implementation. Although I subscribe to decentralization, I have strong reservations regarding dictating how "things are supposed to be".
I sympathize with your reservations, but disagree with this:
"they will be abandoned eventually in favor of ones that do"
This is not what happens by default, otherwise people would have long ago abandoned Twitter, Instagram, Facebook and so on and moved to Mastodon and they would be abandoning everything now and moving to Nostr. Although that can happen it's far from guaranteed and making people aware of the problems through harsh notes is part of trying to make it happen.
As I said, they're not flawless, but they can definitely help. Coming up with an example in which they break doesn't imply they're horrible and should not be used.
You have just cited a wrong claim from the hodlbod without addressing any of my points. In case you want to do that, here are some more points for you to address:
View article →Oh, to answer you: most clients (aside from Snort, Coracle, Gossip, Voyage as far as I know) implement some variation of the "manual relay list + flood requests" I mentioned in the note quoted above.
Nah, that specific quote isn’t wrong. 🦖
You do outbox your way, I’ll do outbox my way. Let’s test who has more missing notes after.✌️
The example I gave is literally the main value proposition of nostr… relay hints sacrifice free agency. Foolish to latch onto Dino tech.
Interesting approach, I had not considered using relay hints indirectly to infer where someone might be if you can't find their 10002.
Never has
I just started using Nostr yesterday but it seems like I picked the right client... Gossip is rendering the items in question perfectly. I actually find it rare that the native desktop client is ahead of the curve.
the personal cost associated to moving from Twitter, Facebook and the like into a different network entirely, rebuilding identity and audience, is disproportionately higher than moving between relays/clients/apps. that is one of the major accomplishments of the specs you defined. I mean, says so right in your initial proposal.
what has happened by default with social networks is that users migrate or join the networks with more MVPs. ever since IRC channels, the oldest I can think of.
but moving inside the nostr network should be mostly painless, unless you make yourself a subject to a totalitarian platform, which I expect to exist. and even then, as long as you hold your key, you might only lose data. you can pat yourself on the back for that, sir. this lack of friction is what enbolds me to say that people will abandon bad platforms, as long as they have an alternative. your protocol provides THAT, above all else.
Even if you implement nostr “perfectly” according to
@fiatjaf , you would still get empty profiles and threads when you run into the fact these smaller relays go down all the time.
Exactly, so using relay hints that list relay URLs in an immutable note is stupid — if the relays go down, the post is toast.
Gossip is a step in the right direction, but it isn’t flawless either due to requiring relays to constantly spread your gossip note. 🗒️
Even with perfect Nostr implementation, frequent downtime of smaller relays leads to empty profiles and threads, highlighting the need for more robust and reliable relay infrastructure.
🎯🙌🫡
Not to mention there is not a standard way for devs to implement it. You can implement it wrong or “right”? The idea that we are getting upset at devs for not implementing nostr right is silly. What is the right way? No one has ever done this write up.
How about write a tutorial or nip? This is much more productive than just shitting on devs for doing the simplest thing when they first get started (relay pool). I guess
@fiatjaf is calling me and many others for not implementing “fiatjafs vision”, but what is this vision exactly? following relay hints? this doesn’t solve everything, the relay hint in a note could be down.
nevent relay hints? nevent didn’t even exist when I started building a client. How is this “obvious”? How do you select the ideal relays for many different types of queries without blowing the connection budget? What client is
@fiatjaf building that has this perfect algorithm? Please teach us.
Honestly jb, I’m going to declare independence from fiatjaf’s madness soon.
I’ve been interested in
@elsat nostrability for maintaining compatibility across clients, as I’m sure you’re aware.
I’m working on a clear standard (list of cleaned up NIPs etc) that others can follow if they don’t want to try to sift through fiatjaf’s madness.
It will avoid relay hints for discovering missing content, and other bad/messy ideas (like NIP04) — distilling the best of #nostr.
Most of it aligns with Damus etc, but I’ve got a new outbox method that I’m eager to share soon. It doesn’t rely on the blockchain at all… it’s free and fast.
You all can be the judge of it soon.
Nostr is not what fiatjaf says it is. He helped start it, but I suspect the people are going to be the ones to scale it. People like us. Personally, I see fiatjaf almost always arguing in a disingenuous way — then he blames others for not knowing what to do.
As long as we create a standard that many clients can follow in a compatible way, we don’t need his mad king behavior.
🫂
Help us
@Terry Yiu @Montzstar
You are our only hope
#nostrsdk
What do you mean "It doesn't rely on the blockchain at all" ?
Who is building anything here that relies on the blockchain?
An old spec of mine tried to solve the consistency problem of Nostr by putting merkle roots of profiles on-chain. It was just too expensive for users & totally not scalable. Back when I first joined Nostr two years ago. I can admit when I was wrong. Have iterated since then.
Hmm.. We need to have the right incentives for more and better event transmissions to relays? Goal could be broader event distribution among the network of relays.
Oh yes he did.
On Jan 5, 2023, in my very first telegram convo with fiatjaf, he said:
"I think clients must not talk to a bunch of relays as if they were all the same"
and then
"I think they must find and follow people in wherever relays they are"
to which I said
"This is a paradigm nobody seems to understand or talk about except you and I. Lots of people are confused about how it could possibly work, and there is some massive event duplication going on in the background."
to which fiatjaf said
"I've been talking about that incessantly"
Based on that final statement, I'd say fiatjaf was saying this before the gossip client was doing it. So with that I disclaim all responsibility, I didn't start this thing ;-)
There was no NIP saying this, and NIPs are all optional anyways.
This discussion has come up over and over and we have not settled on a direction, the community has instead split. I *hate* telling people what to do, I think people are free to copy notes and avoid connecting to strange relays and I *still* have mad respect for all the devs who do it that way.
I'm not sure it has to be one way or the other BUT I will stump for my way, and you have to live with the consequences of your way. For example, not being able to see fiatjaf's quote posts, running massively overloaded relays, finding it easier to be banned from nostr than you thought, burning through network traffic between relays, realizing you have faux-privacy and you've actually just deceived your users by only patching the biggest privacy holes while leaving the little ones open, etc.
To me it is just decision -> consequence. I don't care what other people choose to do, but I will try to predict the consequences.
All good. Btw all your quote posts should be loading in Nostur because it does follow nevent relay hints but I noticed for some reason they weren't loading half of the time, just fixed a bug related to that.
Yes, I know people were seeing the posts on Nostur, there were many screenshots here over the last few days and people claiming that it was working on Nostur, which has probably contributed to my belief that Nostur already had some kind of outbox model implemented and made me gain hope for the world, only for it to be crushed later when I confirmed it didn't.
thanks for the history lesson. appreciate you building the way you see fit and please recognize I do not take the opposite view - I’m merely adding my observations.
I think read/write to all relays is a bad design as well and have said as much since I joined the protocol in dec ‘22.
@ben has been unassumingly right about almost everything I’ve seen him talk about, and proved so over time. He’s that unassuming guy in the room that somehow sees what others don’t, but wants out of the room to get back outside to live and do rather than talk.
@fiatjaf could provide automated Tests as requirements so people who implement it can be sure it's working right
