Probably your follow list doesn’t fit in most nostr relays.
We have categorized people sets so using that you can “follow” as many people as a normal human would want.
Outbox Bootstrap relays (i.e. purple pages) could be a good way to get an idea of these follows lists, but yes, agreed it’s an unsolvable problem. (Well, problem is an overstatement; it’s a stupid legacy metric that was always bullshit in centralized platforms)
@fiatjaf had a cool idea about using probabilistic COUNTs based on HyperLogLog to aggregate large sets of data across multiple relays without downloading all the data multiple times and having an estimation of the duplicates.
The design space is very large, rapidly expanding and we are very early discovering where all this is going.
Patience, introspection and neuroplasticity are a must to thrive in nostr building.
An honor and a privilege to explore this vast unknown with you all.
https://sovereignengineering.io/assets/images/geocities.jpg
FAKE NEWS
To be clear, because @fiatjaf ‘s sarcasm is often misread; I like option b better but I don’t think it’s fully realistic looking at where nostr has been moving in the past two years; option c is more natural and emerges spontaneously and I think nostr can work perfectly well with it.
(And just to be even more pedantic, I recently suggested option c to some people)
What I do think will happen is that people putting out podcasts, videos, long forms and books will, the vast majority (~99%) of them, write a tweet announcing that they published something new (this is what I implemented in the highlighter.com publication flow indeed)
So clients that render both the kind:1 and the long-form will render both in the feed, which might look spammy (“why is this guy I follow showing he just wrote an article about kind-maximalism twice in a row??!”)
I think that’s fine too, might look a bit weird but that’s ok and clients could do something to filter them out if it becomes a problem.
nostr:note1qqqr6h59qxcq40c5sfge4f7u8gfd3t99ae4p6z6u2zglg567e8jslg4lty
I have similar thoughts but I ultimately think it’s a bad idea; one of the powers of nostr is the portability of the social graph and starting from scratch on each use case breaks a lot of what’s cool about it.
That said, being able to fork your follow list, or have some slight modification to your kind:3 could be very cool and depends a lot on the use case.
FWIW, I don’t think it’s a per-kind follow list, but more a per-use case list, like I might be interested in someone’s thinking and want to follow them and also follow their highlights, long forms and podcasts but their music taste sucks and I want to not have them in my music follow list.
Agreed on paragraph #2. I changed my opinion recently about this and I think it solves some problems.
I think it depends a lot, some follow lists will have huge overlaps with your kind:3, some will have no overlap.
It would suck for me to have to re-follow all the people I’m interested in reading long-forms because that’s pretty much exactly my kind:3.
To be clear; it’s a different event, what I’m talking about is the tooling to make this empowering instead of detrimental to people using this.
@Fabian where does Nostur get the key I’m signing as? I made this pubkey months ago and no matter what I do it always signs with this nsec; I even removed all the accounts, it still signs with it when I’m signed in as my main pubkey 😓
nostr:note1n28drew24jshmkdndv3w7f68hw05cuvx34dpzlwcf009d0tq2ckqu3u405
Yeah, I think it’s showing me the wrong nsec; also if I try to edit my kind 0’it (obviously) fails (it thinks it works but when I check somewhere else the event wasn’t published)
Don’t put your cold storage in it; that’s not what it’s for.
And you can symmetrically encrypt with a pass phrase so that a client needs your explicit authorization beyond access to your nsec
Ultimately, as in anything that frees individuals, is up to each person to choose how to use the tools.
You’d still need to OTS it though since an attacker could do exactly the same with establishing the threshold.
I don’t think you can get around requiring ordering if the source of truth is the key in question.
That said, we have a pretty secure source of time ordering and OTSing is quite simple, cheap, and you only need to verify it under a very rare circumstance 🤷♂️
I think this is far simpler: don't support grossly broken implementations or the surface area for the protocol will be infinite.
I would much rather use a client that either ignores bad events or even better displays them with a nice warning saying "person X published a horrible event, click here to tell them to complain about their broken client" -- Ideally it would check if there's a `client` tag with a NIP-89 and p-tag the author of the client.
I was half kidding, but certainly extending the surface area with bugs and/or misunderstandings of every developer will make it impossible to operate in nostr
Wrapping up an insane first week with the @Sovereign Engineering SEC-03 (the most bullish week we had _so far_) by listening to @NVK , @jb55, @miljan and @hodlbod .
Great rip; ecstatic to hear how they are thinking around these building blocks to build feeds (DVMs, nostrscript, coracle’s) not as competitors but as composable pieces.
Give this a listen 👇
https://fountain.fm/episode/rrZNKoROI34ccbuWesrW
80% of nostr misunderstanding (particularly wrt scaling) comes from not understanding how something like outbox would work.
which is fucking retarded.
the “public square” use case of nostr basically implies (something like) outbox; it’s like saying nostr can’t work because people can’t do math that quickly since the spec doesn’t mention computers.
Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
📢 Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
https://m.primal.net/LZtF.mp4nostr:note1q8rnnu4ss798ue88400r5ytej50uzhx87d775q6jev7hs64tj2ksf2nkh2
immediately after demoing this at #SovEng we started whiteboarding the read for this; there's already people working on implementing it -- they will probably have something usable by the end of the week 😀
Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
📢 Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
https://m.primal.net/LZtF.mp4nostr:note1q8rnnu4ss798ue88400r5ytej50uzhx87d775q6jev7hs64tj2ksf2nkh2
@NunyaBidness can you try to login into Shipyard.pub now? it should work and note scheduling should be running smoothly again.
LMK!
(I scheduled this note to be published 5 minutes from now, so if you're seeing this it's definitely working)
https://media.tenor.com/MCr-3uhWGn8AAAAM/seinfeld-airport.gif
Screens are terrible and should be nowhere near a kid.
Our relationship with our 6yo improved 100x a few years ago when we went from "a little bit of screentime" to "absolutely no screentime ever"
Highly recommend.
yeah, we actually started when she was three.
She got actually got hooked when we caved and gave her a phone on a flight from Europe to Costa Rica.
Right after that it was all but impossible to take the phone away and we struggled for a long time (~1 year) to contain screentime. I think she was around 3.5 y when we decided we were going to go from 15 minutes a day to complete zero.
Like @vrod said, it's rough at the beginning and you have to be super present to be with them, but also allow for boredom to come in and not fill the boredom with some exogenous stimuli.
we gotta meet people where they're at to help free them from a much worse monster
I think the idea you told me in Nashville can have a very positive impact wrt addiction
cc @Fabian (developer of Nostur)
don't know what it checks, but I see your events, and your profile just fine
you really can't delete your "account" just like you can't delete the number 4 -- there is no account really 😅
Oddbean new post about login | logout
Notes by PABLOF7z | export