Bingo!
And how could I deny having a fat crush on nostr:npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv.... ๐ซฃ
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z I bet we can debug your replaceable event bug by looking at strfry logs, I've been getting rather good at that these days. Very hard to tell what's happening without doing that while simultaneously hitting it with a client.
Basically we just spin up a relay to test with, optionally turn on full debug log and point the sheets at it. Could be the relay is receiving events out of order from multiple connections or something like this.. (or an actual bug in strfry tho I would be surprised if it is).
New fetish unlocked
Close enough! Plenty of applications doing it these days.
I'll be exploring SiYuan and Bear notes soon!
I think these apps will scale well with the information management demands of Nostr.
Skeptical, yes, but I think there is plenty of potential value proposition for many implementations of WoT. However, I would argue that it is still being integrated poorly. This is no fault of WoT devs.
nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q is who I would call upon for a good counter-argument in general.
I will argue both in favor as well as against WoT because I see things differently, but let it be stated that I am not much of a developer, so my perspective may be skewed.
(Warning, this post is kinda long)
I had never heard of Web of Trust until I found nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 on GitHub, and I followed his ideas as best as I could. I basically harassed him to educate me to the best of his abilities about Web of Trust for about one year. At many times his arguments seem very promising but perhaps seemingly short-sighted, though again, I wouldn't place this "burden of proper WoT implementation" on an "amateur WoT dev".
I make these distinctions because I believe in the freedom tech movement as much as the next purple-feathered dingo, and I recognize that nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 wasn't much of a developer either until Nostr encouraged him to keep pursuing his idea of WoT. Watching his progress has been even more satisfying than watching my own.
In any case, how this relates to your question- I've been getting to know nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h and his relay.tools project, and it has me considering what I've thought about Nostr since I got here (~2 years).
Relays are flexible as proven by many applications.
They can be decidedly ephemeral or attempt to maintain permanence.
What impresses me most is the versatility of Blastr. In my mind there will be various structures to the Nostr network which will continue to take full advantage of Blastr indefinitely. When Nostr says censorship resistance, I say BLASTR is the WAY.
But not everything needs to be Blasted.
So, relay.tools is implementing NIP-42(?) auth which should take care of that and provide ephemeral identities.
At this point in my mind, any instance of relay.tools now has the same "problem" of Nostr.
"What client is going to integrate with this?"
Or, "What does a client with on-demand relays look like?"
And, yeah, that's a tough question, cloud.
I am fully confident in the direction things are heading.
But again, the question. What is WoT for?
I think it's for relays.
I think with relay.tools we will be able to maintain decentralized distribution of relays that SCALE.
And I think it's important that it be done this way.
We will be able to create communities of relays based on endorsements from the administrators and users.
We will be able to replicate entire collections of relays from one domain to the next.
Nostr is a flood and WoT is the wind.
It's the direction we choose. The people we trust. It's a trust metric.
But I don't trust npubs.
I trust heavily endorsed networks of relays, especially when that trust score is heavily procured by my own follow list.
By enabling what I call "operational relays" to exist separately with relaytools, we can manage authority structures locally at the domain level, as well as allow users to migrate from one domain to the next, irregardless of client.
I believe relay.tools is the future API of scalable Nostr relays and Web of Trust will be our way of sorting signal from noise, down to the personal level, inclusive of client and server levels, and always maintaining total decentralization at the client level, thanks to #Nostr.
This is what I see as someone who merely considers themselves a user at this time.
When Listr.lol becomes Logseq.lol we will have a better tool for managing complex, personal lists of user data.
This kind of application is in development. I found someone on here who is building a client for that too. When I suggested collaborative editing, they seemed on board with that too.
The future is fucking BRIGHT king.
WoT is not the answer, it is merely our way of filtering signal from noise. But it starts at the relay level.
Prove me right or wrong but I hope all of you are aware of how awesome you are. ๐ฏ
nostr:npub1da72xwy4h4727jyqmcxw8dzhzyq8ghr634csuze4gyhnu2guv5uqm3ez52 is working a Logseq type of application for interoperating with relays.
I wonder what kind of a headache that must be.
I also wonder if the honorable nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc has used Logseq ๐ค
Thank you for your response! I tried to zap you but am having an issue apparently.
In any case, upon review of NIP-29, I disagree with this part. I can see where it's coming from but I don't think relays can operate as a divided community. Rather, I think relays are individual communities. In my mind, consolidation into archival or decay is the natural progression of conversation, and I think primarily relays are used to transmit conversation.
The other stuff would be, like lists, and operational data, protocol-based stuff.
As it stands we can embrace protocol-wide communities by empowering relay.tools with a client that enables this.
As a simple start we can merely opt for affiliated relays. If I begin a community about mushrooms, and someone else begins a community about specifically red mushrooms, it makes sense for both relays to affiliate with each other to encourage growth and distribution of content.
This begins with operational relays, at the domain level. Various protocol data can be broken up and managed in a decentralized construct, while being hosted and controlled in tandem.
This allows for flexible navigation and management by users. They decide what level of the protocol they wish to exercise. They decide when to migrate, or when to post, or delete, or make changes.
By doing so, we can store the NIP-51 lists of affiliate relays on an operational relay for the host of the example relays.
For instance:
I start a website called foragers.dev
I spin up an instance of relay.tools
I decide I want to host three relays:
n/Foraging
n/Growing
n/PenisEnvy
Upon initialization of relay.tools (in theory), you would be prompted with the ability to offer multiple domain-level relay configurations. I can't begin to imagine all of the potential stack flows of Nostr servers, but I can imagine that there would be more than one, depending on the client's goals.
Everything you can separate to its own relay reduces the load of the "initial operational relay".
So let's start with the primary relay, which will initially operate as the basis for the domain itself. n/Foraging would offer the "total suite" of operational relays. The user would decide if they want to separate any particular data on their own accord. But initially they will configure their own stack if necessary.
n/Growing would be (in this example) a resource-based relay. Let's say I aim to fill this section with guides for growing healthy mushrooms. My users are happy to help embrace this goal and we all decide there are some other useful relays we want to affiliate with.
But, oh no! Their relay isn't hosted on our server!
That's okay, because collectively, the users will form a list of the most relevant relays, and they will publish it to the domain-level operational relay. This will allow the domain to know who to advertise, specifically on behalf of a single relay, and only in congruence with the specified relay. Think of this like one subreddit recommending a list of recommended subs.
When the relay gets deleted, along goes the domain-level lists that went with it.
If a relay migrates? Initalizate a migration (in theory). The destination relay is hosted with relay.tools ? Great, it recognizes the signed events, and authorizes the initial instance of relay.tools to Blast those relevant domain-level events.
And Web of Trust?
Well, that becomes a domain-level operation.
Thank you! ๐ Your comment made my morning!
Skeptical, yes, but I think there is plenty of potential value proposition for many implementations of WoT. However, I would argue that it is still being integrated poorly. This is no fault of WoT devs.
nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q is who I would call upon for a good counter-argument in general.
I will argue both in favor as well as against WoT because I see things differently, but let it be stated that I am not much of a developer, so my perspective may be skewed.
(Warning, this post is kinda long)
I had never heard of Web of Trust until I found nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 on GitHub, and I followed his ideas as best as I could. I basically harassed him to educate me to the best of his abilities about Web of Trust for about one year. At many times his arguments seem very promising but perhaps seemingly short-sighted, though again, I wouldn't place this "burden of proper WoT implementation" on an "amateur WoT dev".
I make these distinctions because I believe in the freedom tech movement as much as the next purple-feathered dingo, and I recognize that nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 wasn't much of a developer either until Nostr encouraged him to keep pursuing his idea of WoT. Watching his progress has been even more satisfying than watching my own.
In any case, how this relates to your question- I've been getting to know nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h and his relay.tools project, and it has me considering what I've thought about Nostr since I got here (~2 years).
Relays are flexible as proven by many applications.
They can be decidedly ephemeral or attempt to maintain permanence.
What impresses me most is the versatility of Blastr. In my mind there will be various structures to the Nostr network which will continue to take full advantage of Blastr indefinitely. When Nostr says censorship resistance, I say BLASTR is the WAY.
But not everything needs to be Blasted.
So, relay.tools is implementing NIP-42(?) auth which should take care of that and provide ephemeral identities.
At this point in my mind, any instance of relay.tools now has the same "problem" of Nostr.
"What client is going to integrate with this?"
Or, "What does a client with on-demand relays look like?"
And, yeah, that's a tough question, cloud.
I am fully confident in the direction things are heading.
But again, the question. What is WoT for?
I think it's for relays.
I think with relay.tools we will be able to maintain decentralized distribution of relays that SCALE.
And I think it's important that it be done this way.
We will be able to create communities of relays based on endorsements from the administrators and users.
We will be able to replicate entire collections of relays from one domain to the next.
Nostr is a flood and WoT is the wind.
It's the direction we choose. The people we trust. It's a trust metric.
But I don't trust npubs.
I trust heavily endorsed networks of relays, especially when that trust score is heavily procured by my own follow list.
By enabling what I call "operational relays" to exist separately with relaytools, we can manage authority structures locally at the domain level, as well as allow users to migrate from one domain to the next, irregardless of client.
I believe relay.tools is the future API of scalable Nostr relays and Web of Trust will be our way of sorting signal from noise, down to the personal level, inclusive of client and server levels, and always maintaining total decentralization at the client level, thanks to #Nostr.
This is what I see as someone who merely considers themselves a user at this time.
When Listr.lol becomes Logseq.lol we will have a better tool for managing complex, personal lists of user data.
This kind of application is in development. I found someone on here who is building a client for that too. When I suggested collaborative editing, they seemed on board with that too.
The future is fucking BRIGHT king.
WoT is not the answer, it is merely our way of filtering signal from noise. But it starts at the relay level.
Prove me right or wrong but I hope all of you are aware of how awesome you are. ๐ฏ
Slowly starting to forget the time when social media felt like a garbage disposal. ๐๏ธ
Now it feels like a light breeze. ๐
A gentle reminder that there are always people working in the space between the lines. ๐
A warm cup of tea to soften the crushing bite of reality. โ
A glimpse into the magnificent pillars of sunshine that hold up the sky in succinctly cascading arrays. ๐
I often wonder,
What is the ideal ratio of signal to noise? ๐๐จ
How can I best express myself without being misinterpreted, often by total strangers? ๐ฃ๏ธ๐
What are the most attainable means of reaching meaningful consensus? ๐๐๐ ๐
What can be learned from the successes, and failures, of others? ๐ง
How can I have the most impact? ๐ค
But I'm glad that when I open my feed, everyone has their own agenda. ๐๏ธ
"No one can stop Nostr, therefore no one can stop me."
Be #ungovernable, and be unashamed.
#Nostr is organic, emergent technology.
Just like #Bitcoin.
If you're reading this, I support you wholeheartedly in all that you are doing. Keep up the great work. You will make people proud.
#Hivetalk is a good example of what can be done in the short term as opposed to over-romanticizing the long-term. ๐๐ฏ
Bees don't waste their time explaining to flies that honey is better than shit.
Inclusivity > Exclusivity
You reap what you sow. ๐ฑ
Thank you again ๐ I'll let you know if there are results ๐คฃ
๐ฑ Thank you!! That is a lot of good info. I was thinking I might try to twist or break off the whole clump but I'll have to look into storage methods and time-frames.. seems like I should just cut a piece off? ๐คฃ
What I'm most scared of is uprooting it and preventing it from growing back ๐คฃ Probably not something I need to worry about but idk. Any foraging tips? I have so much to learn ๐
It's brand new! There are actually multiple specimens that I'm aware of. This one always grows pale like this, but admittedly I don't know enough about them to feel confident eating them just yet. I will continue to investigate this one and hope for the best. ๐
My Chicken of the Woods grows back in the same spot every year ๐
Might have to fuck around and cook some.
#mycology #vegan
A natural and respectable pivot of interest.
If you're on #Android try out #NiagaraLauncher for a clean and comfy home screen:
https://get.niagaralauncher.app/HRYKI0
Been using the free version for years now with zero complaints. ๐
This referral link will give you 50 days of Niagara Pro for free โจ
BitAbs