aaron
A. A. RON

Public Key

npub14lu6nuqh7v4jazmqw49yzqkmnkw0nletjeuqfdgwqurcp2j9ex5qz37m8m

Profile Code

nprofile1qqs2l7df7qtlx2ew3ds82jjpqtdem88elu4ev7qyk58qwpuq4fzun2qprdmhxue69uhkummnw3ez6ur4vgh8xetdd9ek7mpwv3jhvqgkwaehxw309ajkgetw9ehx7um5wghxcctwvshshyj4u7

Publishing to

nostr-pub.semisol.dev

eden.nostr.land

relay.damus.io

Author Public Key

npub14lu6nuqh7v4jazmqw49yzqkmnkw0nletjeuqfdgwqurcp2j9ex5qz37m8m

Show more details

Last Notes

2023-02-25 17:28:50

monstr is cool.

2023-02-17 04:20:39

There was a time when I was probably seeing most of my follow’s content.
But I’ve been out of the loop for a while and paid relays have z̶a̶p̶p̶e̶d̶ taken off.
So I’m probably missing everything now.

2023-02-09 15:53:20

- reply

I’ll keep the relay code open source and will contribute esp if anyone submits an issue. There are bigger features I’d like to do eventually (like virtual relays) so if things change and I can get more time for side projects I’ll hope to get back involved more.

2023-02-09 14:38:53

nostr-relay.untethr.me likely to shut down this month.
I only have a couple hours a week to work on it and have to be realistic about supporting it going forward esp. as spam starts to find in.
Will wait a while for all the mission critical apps using it to migrate away.
Joking aside, I’ll have a backup and can get posts exported for anyone who needs but I bet everyone is already covered by other relays. Beauty of nostr.

2023-02-08 07:32:23

- reply

This is cool idea. Although imagine solving 10 riddles for 10 relays every time you login.

2023-02-08 07:30:28

- reply

Nice gtk. I should just do that as there’s no reason not to.

2023-02-08 03:58:56

- reply

The problem is finding a prompt that is not machine-solvable, but at the same time solvable by the masses.

2023-02-08 02:52:54

- reply

I was thinking of posting an riddle per hour where the answer was a simple word or phrase - not solvable by machine.
Any pubkey that signed an event to my relay in that hour (system time, not created_at) would get minted and permitted to post.

2023-02-08 02:49:56

- reply

Will the paid relayers hear us if we mock them from this ever-towering, sweltering pile of spam?

2023-02-08 02:43:45

- reply

Yeah but from what I understand the spammers will come and defeat everything unless you have a troop of moderators with algo exoskeletons.

2023-02-08 02:34:59

- reply

How does that scale?
Joe doesn’t even know what a sat is.

2023-02-08 02:27:38

- reply

Yep.
There has to be some automation + humans in the loop to be effective and I don’t see how you can get away w/o POW or captcha or pay something pubkeys.
Seems like many core nostr peeps are moving to sats pay relays.
Good but I don’t see how that scales.

2023-02-08 02:15:07

- reply

2023-02-08 01:19:01

sqlite just magically stopped using the obvious index it has been using since the dawn of my relay taking queries from <1ms to >200ms
easy fix is to frequently `pragma analyze` but something about this makes me want to capitulate + cut over to an embedded kv - sql isn’t giving enough to pay for this

2023-02-08 01:11:10

- reply

They’re called ‘persistent data structures’ in the literature
*pushes glasses up nose*

2023-02-08 00:20:01

- reply

nip01 specifies querying event authors & ids by prefix. Some client out there queries relays using prefixes to get home feeds. Was interested in why they do it that way.

2023-02-08 00:17:06

- reply

I didn’t tag you. How could you possibly have seen this?

2023-02-07 05:07:46

- reply

fiatjaf

2023-02-07 04:45:23

Who’s the keynote speaker this year at #nostrica?

2023-02-07 02:34:02

Which client does prefix queries for home feed - just curious?

2023-02-07 01:32:08

- reply

Lol

2023-02-07 01:27:04

- reply

I can’t autocorrect.

2023-02-07 01:26:47

- reply

I fixed gross perf issues in my relay fast last nights just in time for this.

2023-02-07 01:25:51

- reply

There wasn’t a single “nostr” in the reply thread!

2023-02-07 00:52:48

Someone filed a missing persons report on bird.
https://nostr.build/i/nostr.build_2fdba4ed5077ccd006cdbe120b3598fe7b71b1ca19e76b9e0a3eb9e937c2d8d7.jpeg

2023-02-06 05:44:57

안녕히 가세요

2023-02-06 05:44:33

안녕하세요

2023-02-04 21:06:19

My car broke down and I need sats to get a bus ticket.

2023-02-04 20:58:24

- reply

lnbc100u1p3aawxtpp53t92g4mx26f3r87pth56u4sycf6q3uhv4tqmna5qld5wmk5ec8jqdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5fnquxuz3v94hce4vehrxrx62qlfntyuzk5d9e92jfruac2sg9ucs9qyyssqrs2aljruadqpkgjdlz2lwnne4emw26j7yrjnpc44nw8lv2rldy9rltmy8cu7ma9s6qk3wqshtfefx7fm957v0e046e6uup8fvwt0zaspzwfytx

2023-02-04 18:58:40

- reply

Clients need to put some safety in place to stop posting our messages like 5 times. This happened to me the other day from Damus.

2023-02-04 16:20:09

- reply

This will depend to a significant degree on which relay implementation you are using.
If the implementation doesn't use multiple cores, then you won't see much advantage scaling out vcpus.
Also consider what db does the relay use and how do they use it? Does it support concurrent writes?
Does the relay index subscriptions so it doesn't have to iterate on every subscription each time a new event arrives?
Probably we need to improve our relay code. Very modest hardware with little concurrency should be able to support much more than 20 notes per second.
My relay runs on the smallest gcp machine (2 vcpus) and median *note* write latencies are <3ms. This is with little optimization on writes, so should be able to support a least 100s of writes/sec on basic hardware eventually.
Indexing subscriptions should mean the time to dispatch a note to subscription should remain small assuming most subscriptions are not firehose/global feed filters.

2023-02-04 15:44:36

- reply

No, it was to get people to interact with single relays to highlight how bad that experience is in clients right now.

2023-02-04 15:03:41

- reply

How would you distribute query load in this model?
The common query is for notes from a user’s follows.

2023-02-04 12:49:06

Once users are able to navigate to a relay in their client and have a sense of what a given relay (by name) is doing for them (in terms of content, raw performance, bugs, etc) then nostr will see relay innovation explode, relays incentivized to perform, and nostr scale to next level.

2023-02-04 12:39:42

- reply

- Post once a day relay
- post every day relay or your messages delete

2023-02-04 12:35:58

- reply

- relay that lets you post once (or fixed number)
- relay that has hourly rule that changes —- such as for this hour your post must be N words long, or next hour your post must contain a given word, must link to a nyt article, etc
- relay that introduces you to another user or users by tossing you into a private channel together

2023-02-04 12:28:22

- reply

winner

2023-02-04 12:27:20

- reply

*Just* made a note about this -> #[4]

2023-02-04 12:21:48

- reply

An early dumb version that could go a long way might look something like this.
A relay could publish that it supports a given shard of users.
For example, my relay could publish that it supports serving npubs starting with “aa” through “az” and other relays could too.
Now clients just have to tell a user if their relay set doesn’t have enough shard coverage.
Whenever the next order of magnitude of users arrive, relays would want to reshard and other or underutilized relays would need to redeclare shards.
And there would need to be a way to get users on the new shards.
Maybe some kind of registries would be in order here. In fact registries could be the key branded thing that clients watch for censorship and change to new ones etc.
Historical data would have to get shared around for reshards but there could be people out there that just keep archives or in ipfs or something.
You still need clients to keep users able to understand and identify a bad relay share that is censoring or underperforming or even overserving — or a registry that is promoting shards you don’t like.
But I wonder how far you could scale nostr globally with a dumb strategy like this?
Really important is that niche relays should not do anything like this and should find other ways to scale (monetize etc) but this would be for just the “global” nostr network experience only.

2023-02-04 11:26:48

- reply

Elasticsearch would a perfect fit for nostr’s query and access patterns, is linearly scalable, I’m surprised no one has made an ES-based relay yet.

2023-02-04 11:20:53

- reply

Recursive CTE queries are your friend?

2023-02-04 11:18:29

- reply

“does well” not “dies well” lol 🔪

2023-02-04 11:17:34

- reply

Thanks!
I’ve optimized a lot but I still have work to do in certain areas. It’s hung in there but to be fair I’m a mid-tier relay, ie at about 500 concurrent users whereas the biggest are an order of magnitude over that from what I gather.
I’ve loads tested my relay at 10,000 simultaneous active firehose queries and it dies well on modest 2 vcpu hardware.
I would like to think I could serve up to a few 100,000 users on a single basic machine eventually. (But I’ll need to monetize to afford the operational costs towards that point.)

2023-02-04 11:10:36

- reply

Relays availability is not an issue, there are plenty right now.
So users can technically flock around whenever a given relay stops functioning. But that experience might work for niche communities but is obviously is not ideal for any global social network experience.
At bigger scales most relays will bow out because the economics are there. I’m already running a relay at a complete loss per month.
I have a lot of distributed systems experience and it’d be fun to build out nostr but I couldn’t afford to operate a big cluster which you’d need to do to build it right.
Some alternative model would be some kind of sharded peer model where smaller nodes could work together to support global load but need to think how to make that possible and identify bad (flaky or censoring etc) peers.

2023-02-04 11:02:02

- reply

I don’t know of any linearly scalable relays yet. Is that what you’re looking for?
The largest relays have <10,000 concurrent users at this point.

2023-02-04 10:51:46

twitter has so many
“bombshells” over nostr

2023-02-04 05:01:27

I’ll starting to feel like the fact that I don’t always get all replies and notes is a good feature.

2023-02-04 01:21:10

- reply

Tell us more.

2023-02-04 01:03:44

- reply

Your writes are faster than reads?
Maybe cos you’re not paging yet?

2023-02-04 00:58:39

- reply

Interesting. Besides the burst of queries you might get when redeploying a node, what do you see in terms of qps with 8k users?

2023-02-04 00:38:53

- reply

From load testing I should be able to handle couple hundred per second - so 200k plus users. But I need to optimize kind 3 updates because currently I reindex the whole contact list each time.

2023-02-04 00:35:24

- reply

Nice I’m at about 500 concurrent and 0.5/s so almost directly in proportion - 1000 users translate to 1/s… interesting. I assume you’re including all kinds (I am).

2023-02-04 00:12:39

- reply

Niice

2023-02-03 23:59:01

What are the top used relays, what are their concurrent user counts, and notes per second?

2023-02-03 22:00:52

- reply

Awesome
Just fyi I’ve noticed you have a few relays listed double - some with trailing slashes and not … that might cause some clients to double pull from the same relay

2023-02-03 15:42:55

- reply

This makes sense. I think I should make a distinction...
If a client can tell me "hey, this follow of yours is also active on nostr.twitter.com and on nostr.stamp.collectors" then that's incredible and great, sensible information and I can still have a brand relationship to these relays.
But nostr users today are in the spray notes mentality (and clients are underwriting this mentality) where relays have no real brand or semantics -- relays are just hoping to be seen and be found by smart clients.
That is the model that seems wrong because it is the source of some key issues with nostr right now: client bandwidth, missing parent notes, and long latencies (ie, no way to id which relay is dragging my ux).
If we changed away from these model, so many things would be solved, we'd still have censorship resistance, and smart clients with discovery would actually offer that really cool experience.

2023-02-03 05:02:16

- reply

This view solves bandwidth problems.
And it also opens space for relays to flourish, compete, compete for niches.
Because in the spray model today, as a relay you are just sitting there hoping you get some spray because otherwise no one is going to nav to you - which is a real poor place for a relay developer or operator right now.

2023-02-03 04:56:12

The client I’m using just posted my bloviating note three times. Sorry. :(

2023-02-03 04:49:22

- reply

What if we didn't think of it as "my relays"? This is the ubiquitous thinking so far, but I'm beginning to think it's wrong.
I'm working from a key premise that if relays don't effectively become like brands to users then nostr is not going to work at scale and in the long term.
Clients will dominate what users experience in terms of content. (They already are today and this is worrisome.)
When you think about ultimate scale, there will be way fewer clients in use than relays and without users being in a brand-type relationship with relays, you will have centralization for all intents and purposes.
Clients will dictate content and users will know no better.
The idea of "my relay" seems problematic in this context.
Because I, as a user, can't keep track of all users and "their" relay, I now have to relegate this power to clients. I have to stay in this "Twitter"/centralized mindset: I am "on a social network" and I have some follows - now client, go figure this out for me and, in the end, give me this Twitter experience.
This is what clients are doing today - Damus, snort, etc. Not good. At scale, they'll be just like Twitter.
*Instead* if we think about today's browsers - we demand that they give us navigation ability. Browsers fade into the background and what we are really after is this or that branded service or web page. This is good. This is power in the users hands. This is not AOL. This is decentrailization.
We need nostr clients that are browsers like this. What do they browse? They browse relays. Users of these browsers can navigate readily from relay to relay. Form a brand relationship to relays.
Now I will check out what is going on at nostr.twitter.com. Then I will go check out nostr.parler.com. Etc. If you have this then you have the censorship problems we've seen solved (we don't need Carmen Sandiego clients that try to stealthy find our censored follows). Your follows list(s) can go with you but you do not need to abdegate clever stuff to your client that hides it all from you and asks you to trust it.

2023-02-03 04:49:18

- reply

2023-02-03 04:49:14

- reply

2023-02-03 03:34:11

- reply

AUTH = NIP42

2023-02-03 03:02:47

- reply

I will make sure to note which keys validated as nip05 and mark that somewhere. And any key that I make that is paired with a real key will get a nip05 at my relay. So if the original note is from [email protected] then rewritten note will be from [email protected]@crazy.relay and you'll just trust crazy.relay until you don't.

2023-02-03 02:57:46

- reply

This should work because the users are only configured to use this relay.

2023-02-03 02:56:30

- reply

Dammit. Okay, then I'll resign the content under a different key paired with each user. And I'll rewrite queries for users content to use the paired keys. For clients that just render query results, you'll see them in the follows you. But I will *also* return your followers this way for anything that looks like a global feed query - so you can at least see the view there. Now you can post these resigned messages elsewhere but people won't see them on their own follows page.

2023-02-03 02:44:44

Would you use this relay?
You have to AUTH (which clients support AUTH today?) to post.
I'll scan every known relay out there. If your post shows up anywhere else I'll retract it from this relay so that it is no longer served (notifying you by DM of the retraction).
The only content that will remain is whatever is not posted elsewhere. I.e., only users that use this relay alone as a public relay.

2023-02-03 02:29:30

- reply

That looks like it would tickle

2023-02-03 02:27:37

- reply

👍🏿 each relay needs a brand and users need to form a relationships with relays like they do with other content providers out there.

2023-02-03 02:25:07

- reply

Nice relay rankings. 3rd place is the 2nd loser.

2023-02-03 02:04:47

- reply

One thing we should be questioning is the way we’re using (and thinking) about relays today in one capacity...
I think this idea of spraying public relays with our content might be wrong.
And we’re making all these decisions across the board on this idea.
Maybe:
I should really only post a given note to one relay intentionally for public consumption and 1 or more other relays strictly for backup.
Lots of things could be done but imagine some relays offer a /backup endpoint strictly for storage but not to expose publicly.
If I’m censored I can either request one of my backup relays to convert my posts to public or give me an expert so I can post them to a new relay when I want to switch or I am censored.
This would be way better because now there isn’t all this noise in a relay / across relays.
Now the idea of clients becoming browsers of relays makes much more sense and things get a lot clearer for users.
You don’t end up with this “why am I seeing the same post everywhere I go” and, from a design perspective, how do I show users this multiplexed view of a note.
And relays can emerge as identifiable things which they really need to be for nostr to work.
It really doesn’t make sense to spray the way we’re doing it now is what I’m saying.

2023-02-02 05:47:47

- reply

Coool

2023-02-02 05:46:15

- reply

If you have any lessons learned or references back to mastodon attempts and failures you should share with nostr devs on telegram.

2023-02-02 05:45:10

- reply

Depends. I’m currently footing the bill for machine and resources so at some point I’ll have to decide what to do. Most of the cost however is network traffic and not disk. Still I can’t keep going without figuring out how to cover expenses.

2023-02-02 05:42:36

- reply

Clients need to get better at presenting relays to user, letting users *navigate* relays, and understand what content they see is served by which relay. This way users can naturally gravitate to relays based on what they offer. Current clients don’t do this well but there are nostr designers and client developers working on this problem and coming up with cool stuff!

2023-02-02 05:33:18

You can watch my relay database populate by refreshing: https://nostr-relay.untethr.me/q
Earlier I watched some people playing connect four
Add wss://nostr-relay.untethr.me, post a note, and watch your note show up ⬆️
Hmm thinking I should just render a nice pretty branded global feed with nice pubkey quick copy there instead of db dump— and set a precedent for relays to do this

2023-02-02 05:27:37

Okay going to finish this Licorice Pizza

2023-02-02 04:05:17

- reply

Core feature set is there today. Just stand up any reliable open-source relay privately for your organization. Then use snort or hamstr or other pointed at just that relay and chat through the global feed. And DMs for 1:1 discussions.

2023-02-02 02:37:11

- reply

Trees are falling down left and right here.

2023-02-02 01:52:20

- reply

Which relay implementation are you using?

2023-02-01 19:43:03

Does anyone know which client generates subscriptions with this id pattern: `"49bb5662-527f-4b43-a9e9-83cb871640de:HomeFeed1f30"`?

2023-02-01 18:49:09

Testing a thing for a thing.

2023-02-01 03:24:34

- reply