Now, that I have your attention, I'd like to share a word from my sponsors*.

* also me

Reply to this note

Please Login to reply.

Discussion

how would this work for people who aren't administering a relay whitelist tho?

Pulling from Communities that they (publicly or privately) labeled

Yeah, or just, like, use some other list.

Making this The God List has lead to developers designing all of their apps around it and destroying the protocol's biggest design advantage: relays.

other lists have to be supported by the client, that's a major problem.

also, it doesn't have to be public, mute lists have a private section now too.

the main problem really is just that primal pretty much administers the God List and they are extremely biased about who gets on it. the real challenge is a good client to onboard people to. coracle probably could do the job, and even he made it so it can be whitelabeled. the other thing is outreach to other social networks where there might be interest.

True.

I think listing people (instead of communities) and pulling EVERYTHING from said people is still an issue, even if you take away the Follow list as the one-and-only.

Community relays :rocketship:

distributed communities too, with lists created by community administrators.

Shared lists. Yeah, I could add that. Using other people's lists.

But lists aren't really an alternative to relays. They sort of miss the point of the exercise.

routing on networks uses lists, it's lists all the way down.

Yes, a router uses lists, but it isn't a list.

Abandoning control of the hardware layer seems like a net-loss.

if the data needs to be public, it needs to be a list. this is what ip ranges are about. this doesn't translate to keys at all, because they are high entropy unlike address ranges.

the hardware layer has to sacrifice some privacy to enable this.

cryptographic identities for network nodes requires intensive configuration. i'm doing it right now creating a 4 node 6 path wireguard mesh right now

A relay community membership list doesn't need to be public.

i've been thinking about this and it can be a privileged event that only the relay and the author can read, and using bloom filters to designate the list so even if the list is leaked you can only check it one by one to see which npubs are included

Interesting feature, that latter one ✍️

My current exercise is figuring out how to let badge-holders hand out badges.

As in, only if you have the badge can you award that badge to others.

Want to use that as an "Invite link scheme" option for Communities.

Community key should be able to break a chain (tree branch) gone awry.

The Communities can already specify badges as write-access condtions for any of their content types. So this would pair really well with that.

"Just" need to rewrite the badge spec with this (plus make the award event a Relationship event).

you should read up on cryptosystems for this kind of thing. it can be done, i think. it's about key derivation trees

there is the other solution for this too, key registries. but this requires some kind of scheme for non-cryptographic identities. nip-05 might be a candidate for linking things together, i'm just spitballing

Thanks!

- automating badge rejection at the relay level

- apps verifying the tree up to 2-3 levels

I'm wondering if "just" a combo in that vain could be enough and avoid cryptography schemes.

someone has raised an issue about mute lists and it occurs to me that bloom filters could replace explicit lists. more compact data-wise and more obscure in that you can't know if you are on it without testing the filter on your key.

a replaceable event containing a bloom filter could be used for the case you describe.

i'm also going to ponder this idea for a secondary mechanism for defining mute lists on #orly because it is possible to define this event kind as privileged so only the relay can read it as well as the author

Yeah, I am across bloom-filters several times the last week's too.

Still need to grasp its application more to cases like this.

well, i think that it's not really useful for one-off stuff like relay configurations but for distributing them it might make sense, as it saves some on bandwidth. but i'm not seeing a strong case for this. events are not that big in data size, especially not when encoded as raw binary. typically follow lists are like 1/4 or less the size of the json

Also, end the situation that there is anyone on Nostr without a local relay.

That, right there, is the core problem.

And we are working hard to solve it.

local relays definitely are a thing. especially they should have little crons that fetch from other relays. and also there is a great need for inbound routing so users can also have their frens write straight to their relay.

some of these obstacles are systemic issues on the internet that bias against p2p, and most p2p protocols are quite deficient, but largely because of the restriction of routing.

I'm focused on everyone having a local, personal relay that aggregates across a filter, and background-syncs with their client, and remote community relays, and some big search relays.

And the local relays on different devices talk to each other over Bluetooth, WIFI, or remote relays.

I find lists interesting for bookmarks and categorizing npubs, but labels and badges might do that better, so I'm implementing both.

Labels and badges, yuuuussss!

it reminds me, that would be a neat thing, a service you pay a little rent like $2/month and your personal local relay has a custom wireguard style VPN client that uses your nsec for its encryption. i'm pretty sure p256 keys at least (secp256r1) already can be used and 99.99999% of valid secret keys for secp256k1 are valid for p256. this would simplify configuration a lot. you configure the relay with your nsec and the VPN endpoint and you get a username.example.com subdomain.

i could build something like this to add to realy in a matter of a week or less. in fact, i already have a http reverse proxy that could be extended to add a user database that fetches from the service's relays to configure npub->name using nip-05 and that username would also be your subdomain. just probably need to have round-robin DNS to run multiple endpoints and configure the multiple endpoints in the relay and it would switch to another one if it couldn't reach the first option.

if only i had the resources to build this. i do hope i don't get stuck without a serious job prospect by the end of next month, i'm gonna be in a pickle.

That was supposed to be πŸ«‚, sorry. Emoji fat-fingered typo.

Didn't nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl implement something like that?

he did, but i wouldn't want to run a javascript based relay when i have my own perfectly good relay. plus i already have a customised reverse proxy so a lot of the parts required already exist, just needs a bit of glue to join it together and make it easy to install and use. it could directly use your nostr identity also, to make things even simpler. some kind of 30k series configuration kind that is marked privileged that the relays on the connectivity services use to set and read your configuration and subscription status and whatnot.

it's probably a month's work for me to do it. i'm gonna think about it, since i can't be job hunting all day long since there isn't even that many realistic job options for me anyway.

I can see an angry nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 actually do that lol :winkwithtongue:

It was a rookie error.

Kind 3 was probably a mistake, following could have been local or private by default, and assigning public "trust" to people could have been taken a more intentional form, with more structure to it rather than "whoever I want to see posts from I put in this list and now that person gets an endorsement from me".

But following people is still a good thing.

I do think the focus on following people should be drastically reduced (no one can really "follow" more than 100 people) and that we need more opinionated relays like wss://theforest.nostr1.com/ and more tools for browsing relays, recommending relays, publishing to specific relays.

It shouldn't be necessary for a new user to click on a follow button hundreds of times in order to get a feed. Clients shouldn't be required to send many hundreds of REQs (most of which will be about pubkeys that haven't posted anything for months) to a bunch of relays in order to build a default feed. That number can be cut drastically and Nostr can still work fine, in fact much better.

Yeah, it's why Jumble works quite smoothly, even though it's "only" a web app. Just slow-drips in the feed from 1-n relays and basta.

I don't "follow" a lot of people on my Kind 3 list, which means those few people get a noticeable WoT bump from me. Those are clearly npubs I am _actively recommending_.

I added a "lists" filter to the feed, and it reqs for the deduplicated aggregate list of all npub lists I select.

The thing people mess up with lists, is that they don't force-fetch the req.

So, if I am looking at theforest feed and select the nostrdevs feed, it should

* figure out which npubs aren't included in TheForest feed (most/some of the list is probably included, as people tend to share relays with their frens),

* use outboxes, relay hints from their cached notes, NIP-05 relays, and/or aggregators to go out and hunt down _everything_ from those npubs, and update the map. Then the map is theforest-events + list-events, and the list events req is quite small.

Nostrdevs list, I mean. In other words, I expand the current feed with whomever is not already there.

You could also look at the list feed, alone, but leaving it like that, permanently, is why feeds get ossified. Opinionated and/or paid relays create a steady trickling-in of new npubs, that enrich the feed, while the list makes sure you don't miss your faves.

The current follow problem that I have can be solved client-side; where one can see whether the follow is reciprocal (why doesent Amethyst have this?) and how long since that person has been "active." (e.g. likes, zaps, profile updates, posts, replies, etc.) Then it should be trivial to unfollow dead accounts and the follow-list is more meaningful.

The public aspect of follows has a wot side-effect, which is also a primary feature. When I'm searching for a profile, I look to see if anyone I "trust" is also following that profile. When people demonstrate they are either worthless or spammy, they tend to get pruned from most lists. The WoT score based on follow, activity & reciprocity has more power than it regarded to.

What a follow-based WoT means in the context of social media is whether the followed identity is likely to be authentic and of information-value, not necessarily whether you agree with that identity. (I follow nostr:nprofile1qqsx3tq0ylq9g5mha3h8ch8x4gkka792rmddc65v9law3mdq0un2llqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qcev0zp for god's sake)

This stuff about "not needing to press follow a hundred times" and "updating their follow list on the relay every time the button is pressed) has no traction in my mind. One can modify a client to batch follows, like in nostr:nprofile1qqsrjerj9rhamu30sjnuudk3zxeh3njl852mssqng7z4up9jfj8yupqpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsfrt6ps. What you are describing is personal feed curation, and many intend this to be public. Some people may want a public follow list, and several separate private follow lists (to avoid endorsement), but this is a power-user feature, and probably too complicated for the "average" person.

To separate the WoT feature from the follow feature is an interesting idea, but also likely to never be useful due to lack of use. Normally people have no idea whether a person they are following is a real person, or even an honest person. In that regard, a "trust" button would never EVER be used. The purpose of a follow-backed WoT is not to endorse, it's so others can see what you want to see, regardless if you "endorse" them or not.

> In that regard, a "trust" button would never EVER be used.

Yes, I don't think there should be a "trust" button. "Trust" is too vague, too generic, not a good word. I would never click that one either.

But perhaps you have a list of uber drivers you like, or a list of wiki authors you favor over others, a list of people with music tastes you endorse etc. I don't know.

> The public aspect of follows has a wot side-effect, which is also a primary feature.

I agree, but it's also too limited. Other possibilities exist and they're not being explored. Mainly in my mind right now is the idea that by following some relays you're open to see posts from people you don't know, and that you trust that relay enough to accept their judgement about who is a person that is worth listening to, and they can have clearer criteria more uniformly enforced, like "whoever pays", "whoever gets manually approved by such and such", "whoever has produced these many hashes", "whoever has a PhD", I don't know (of course since follow lists can still exist this can also be based on the current WoT criteria).

Agreed. The ability to follow a curated relay output could be very powerful, but how is that different to the end-user than subscribing to a curated list published by individuals? One could pay to be on that list, in addition to being curated/endorsed, without needing the list owner to run a relay.

We already have that. Those are the recommendation lists, like the one Primal users are fed during onboarding. Or the follow packs, or shared lists on Listr.lol

The main difference is that a document (list) has no utility to anyone, other than controlling access. A relay is a holistic community of related services, that has limited/predefined criteria for access.

That sounds like a minor difference, but in practice, they're two completely different things.

a list β‰  a server

All relays have lists, no lists have relays.

I understand, but I still fail to see the vision of subscribing to a relay when you could instead subscribe/unsubscribe to a curated list (like a privately controlled hashtag, but for people instead of individual posts).

WoT is about endorsement. That's why it has "trust" in the name.

Knowing who some npub follows doesn't necessarily tell me anything at all, about what they're actually looking at. I used to have over 1k follows, and I just looked at my relay feeds and some lists. You would need the relay traffic to know, and you can't necessarily monitor all of their relays.

I was happy to follow everyone back because it didn't mean anything.

> The current follow problem that I have can be solved client-side; where one can see whether the follow is reciprocal (why doesent Amethyst have this?) and how long since that person has been "active." (e.g. likes, zaps, profile updates, posts, replies, etc.) Then it should be trivial to unfollow dead accounts and the follow-list is more meaningful.

We actually have mini-clients that do this. I've used them, repeatedly, but it quickly leads to a dull, low-signal feed because the people who are the most-interesting to read are also often the ones that post less-frequently or more often on private or protected/AUTH relays, and they are much much less-likely to "follow back".

I'm well aware that my nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z account has a rock-bottom WoT, because it has no follows, and my nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl has a lowish one, as I don't follow that many npubs, but I leave it like that, on purpose. In protest. I think follows are commie, designed to reduce our freedom, create rampant shadow-banning, force us to make all of our contacts public and easily searchable, and steer us all to be drooling influencer groupies.

Everything I've seen happen, on Nostr, since I got here, just solidifies that opinion for me. There has not been any counter-evidence. The whole situation has just steadily degraded.

Most people disagree with me, and cannot imagine how Nostr could work well without Kind 03, but I am not Most People and never have been.

my second degree of follows auto-whitelist design makes it possible for outbox model and personal relays to actually work. the "owners" of a relay have follow lists, and all the npubs on that follow list are spidered to find their follow lists, and from that the relay generates a whitelist automatically that changes whenever users update their lists.

it's a repurposing of kind 3 that i think makes sense - it makes a complete list of all the people who i might want to read or message.

with this list created, my personal relay functions effectively as inbox/outbox and so long as the people in the first and second degree of the owners follow graph use auth, they can post to the relay.

one of the things i have discovered, though, is the great majority of people are using clients that pick up these relay lists and then spam the heck out of the relay trying to publish events to it... but they don't bother authing. oh so sad. doesn't really use that much bandwidth, so idc. but the people who use good clients that do auth, and are in my second degree graph, are found on my relay. and there's quite a few of my follows that do.

the fly in the ointment is just the attitude of most funded client devs not giving a damn about implementing auth properly. but, seriously, fuck them. you can easy enough let your frens know "hey, i don't see your events on my relay, what client are you using? because it's ghey, i recommend x, y and z" and if the other person cares, they try that and voila. connectivity, without centralization.

> I'm well aware that my nostr:nprofile1qqs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgpzpmhxue69uhkummnw3ezumrpdejqzyrhwden5te0dehhxarj9emkjmn9qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tc7xx9t4 account has a rock-bottom WoT, because it has no follows, and my nostr:nprofile1qqsd6ejdteqpvse63ntf7qz6u9yqspp4z7ymt8094urzwm0x2ceaxxgprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qgmwaehxw309a3ksunfwd68q6tvdshxummnw3erztnrdakszyrhwden5te0dehhxarj9ekxzmny7dky6k has a lowish one, as I don't follow that many npubs, but I leave it like that, on purpose.

Your sense of WoT is reverse to the way I understand it. If your nostr:nprofile1qqs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgpzpmhxue69uhkummnw3ezumrpdejqzyrhwden5te0dehhxarj9emkjmn9qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tc7xx9t4 account follows someone, that doesent increase your own WoT; rather it depends on who follows the nostr:nprofile1qqs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgpzpmhxue69uhkummnw3ezumrpdejqzyrhwden5te0dehhxarj9emkjmn9qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tc7xx9t4 account that increases the score. Yes, you don't follow anyone, but that only means you don't need reciprocity due to your own established credibility. The WoT idea is that "high trust" people (who has *your* "trust" which depends on your own follow list and the trust score of who they follow) are depended upon to only follow high-value identities. If your "friend" is following a bunch spam (evidenced by their reposting of crap accounts), you will hopefully unfollow them due to the low value of their posts. Its this score that gives credibility, but only in the sense that the accounts aren't spammers or imposters. The purpose of this WoT isn't necessarily to know who you *should* follow, but to filter out who you *shouldn't* follow and clutter up your feed.

Not having follows is one major reason why I get muted so much and have surprisingly few follows. There are scripts that auto-mute and/or auto-unfollow anyone without follows. It's also a major reason why people refuse to follow me, as they only do the follow-back thing.

My npubs have lots of mutes (also just because I'm such a horrible person and I make people feel unsafe πŸ™„), which counts negatively toward WoT, and some of the algos deduct points for not having follows, on principle, as we're seen as "refusing to WoT with others", so we get actively penalized.

Maybe the solution is to standardize on a WoT schema, which includes allowing people to decide what contributes to the score and set their own thresholds for muting. I think your beef is with clients that make it difficult to see people on a ban liat, and/or with being binned in with bots and spammers.

As long as follow feeds dominate, I will always be in the bin. Along with anyone new.

> I think follows are commie, designed to reduce our freedom, create rampant shadow-banning, force us to make all of our contacts public and easily searchable, and steer us all to be drooling influencer groupies.

>

> Everything I've seen happen, on Nostr, since I got here, just solidifies that opinion for me. There has not been any counter-evidence. The whole situation has just steadily degraded.

I'm not sure you understand the main value most people get out of social media. For most, the purpose *is* to be a "drooling influencer groupie". I would bet nostr:nprofile1qqsgydql3q4ka27d9wnlrmus4tvkrnc8ftc4h8h5fgyln54gl0a7dgspp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg4waehxw309aex2mrp0yhx6mmnw3ezuur4vgkhjsen and nostr:nprofile1qqs8d3c64cayj8canmky0jap0c3fekjpzwsthdhx4cthd4my8c5u47spzfmhxue69uhhqatjwpkx2urpvuhx2ucpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq36amnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46q6ekpnp have made the same observation: Twitter probably started out slow, with a small contingent of tech-junkies who share a common ideology and high intelligence.

Once it gained networks momentum it gained attention of more widely recognized names, who invested in the platform by sharing their high-signal opinion. Once their "groupies" learned they were on Twitter, they joined primarily to be able to participate in the conversation. This was the original intent, back in the early 90's, why USA Today put journalists' email addresses at the end of their articles; so their readers would be able to shout back, or boot-lick depending on the context.

It was when Twitter became a scientific forum, and a political forum, and a journalist publishing medium, that it exploded with success.

I wouldn't poo-poo the underlying nature of social media, or try to pin it on the common ability to publish who you want in your feed.

It has not escaped my notice that they want to build Twitter 2.0.

Wash, rinse, repeat.

We could generally add the β€œfeed” to this category of problems.

I use nostr to see what people are up to. Like on the internet, I like to seek out information or getting personal recommendations.

I don’t understand these channels/feeds/tags mania since I started not using Twitter in 2010.

It’s all a full-text corpus in the internet, properly addressable, searchable (even better now with RAGs) and with strong authorship (pk crypto).

I also don’t get structured logs btw.

I do not understand what you mean. What is the "feed" problem?

I don’t want to be fed.

I feel like a goose.

I still don't get it. Who is trying to feed you? And what do you want instead?

Damus is feeding me with what people I follow pour into the channel.

I sometimes like it. But I more often do not. It’s often crap/ads/reposts.

And cadence is very uneven. It would already help to prefer notes of people who dont write often over the ones who flood my feed.

It’s the exploring. I am missing this.

That's what all of the visualization and the never-ending linkage is for, on Alexandria. We want people to meander through the notes.

Yeah, that's a good one.

I think we should all stop caring about what other ppl do on nostr, fr who gives a shit about how many ppl users follow

Replace kind 3 with kind 10012.

Isn't that just inboxes?

No, that would be 10002.

10012 is "favorite relays", used by https://jumble.social, https://yakbak.app, https://yakihonne.com.

And probably Nostur, who knows, Nostur has everything.

Ah, okay. I thought they were using 30002s relay sets, but I didn't check.

I've got the 10432 for local relays. Was thinking I could add an option remote relay, for auto-syncing between remote/local mirrors. Like a data tunnel map.

So, right now it's

wss://localhost:4869

wss://localhost:8080

wss://localhost:8081

wss://localhost:8082

But it could be

wss://localhost:4869

wss://localhost:8080

wss://localhost:8081, wss://extremelyprivate.auth

wss://localhost:8082, wss://relay.bakers.com