aaron
A. A. RON

Public Key

npub14lu6nuqh7v4jazmqw49yzqkmnkw0nletjeuqfdgwqurcp2j9ex5qz37m8m

Profile Code

nprofile1qqs2l7df7qtlx2ew3ds82jjpqtdem88elu4ev7qyk58qwpuq4fzun2qlaj882

Publishing to

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: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: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: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:18:29

- reply

“does well” not “dies well” lol 🔪

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 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: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: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 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:14

- reply

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: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: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 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 03:24:34

- reply

wss://nostr-relay.untethr.me

2023-02-01 03:15:38

- reply

hamstr.to

2023-02-01 03:13:38

Spammer, you do not have 11,000 follows—sorry.

2023-02-01 02:54:17

- reply

^^ My son’s first nostr post.

2023-02-01 02:53:08

Do you think Gravitrax are hard?

2023-02-01 02:32:25

When do the indie filmmakers show up?

2023-02-01 02:09:26

- reply

try `wss://nostr-relay.untethr.me`

2023-02-01 01:58:35

- reply

c=3

2023-02-01 01:57:36

Pick your relays. Don't acquiesce that power.

2023-02-01 00:50:49

- reply

It’s somber

2023-02-01 00:47:12

- reply

wut

2023-01-31 05:11:53

Each relay/domain needs to be a brand that users relate to, talk about, come to trust or distrust, to be a thing that gets press, big or small, etc.

2023-01-31 04:13:56

I am only connected to eden. Who can see this?

2023-01-31 02:28:21

- reply

And trust users more and give normie users more credit.

2023-01-31 02:27:30

- reply

in*

2023-01-31 02:27:11

- reply

Innovate and insist on making relays first-class i the user experience and making clients more like relay *browsers*.

2023-01-31 02:23:19

- reply

People can back up data to any and all relays that let them.
They can run their own relays if they need to.
Nostr is amazing.

2023-01-31 02:20:39

- reply

Careful, I’m normcore man!

2023-01-31 02:18:03

What client is going to let me readily and easily view the global feed on Eden? Where are you, client?

2023-01-31 02:12:40

- reply

We need clients and user experiences that expose users to relays so that users can gravity to and “select” relays of quality.
We need this kind of market economy with relays or nostr doesn’t work long term.
We need to stop hiding relays from users.

2023-01-31 02:08:43

- reply

With a more relay-centric client UX, you would visit the global feed of any relay you choose.
Users would naturally gravitate toward relays with more quality feeds.

2023-01-31 01:43:04

- reply

The thing is we need to steer clients away from that behavior, and steer the community away from clients that insist on that behavior (without making this exposed and understood, on the level of UX "understanding", by users).

2023-01-30 03:28:52

- reply

I verified this was an issue on my side. Recently I separated my query indices from my event store. Since this is a super old message, and due to a data truncation I did a while back, my event store had this event, but my index did not. Which is why the write answered it was a "duplicate", but the event did not come back in the query (which uses the indexes). Thanks for looking into this, which helped me identify the cause. Sent you a beer in sats. Cheers.

2023-01-30 03:08:56

- reply

It is working: https://nostr-relay.untethr.me/.well-known/nostr.json - I think snort is not validating them correctly.

2023-01-30 00:18:26

- reply

Would you need to AUTH first? so you know who it is ..

2023-01-30 00:16:53

- reply

Thanks! I’m not a common relay implementation so would be gtk if we’re breaking protocol.
I can see my successful OK response on front end of nostr.watch so by blocking the event but it is getting marked red.

2023-01-29 23:58:34

- reply

Hey! This is cool. I noticed you're marking nostr-relay.untethr.me as restricted write - in both backend and frontend version... Maybe because I'm returning "true"/duplicate per nip20 to your write?

2023-01-28 23:20:12

- reply

You’re not giving normies enough credit
We had AOL - how did we ever get normies off of that?

2023-01-28 22:55:13

- reply

That may be incidental to what I’m saying

2023-01-28 22:44:53

In todays world if someone gets banned from say twitter
I can go find them elsewhere - on rss or email list, what have you
This experience already exists
What doesn’t exist is ^this^ experience for normies
That’s what making relays 1st class is all about—-the normies

2023-01-28 22:41:36

- reply

Broadcasting and roaming around with relays 1st class should be the ux imo

2023-01-28 22:40:11

- reply

Both rss and mastodon have you as an identity at some specific endpoint
With nostr your identity is supposed to be your key and you broadcast *to* endpoints

2023-01-28 22:11:44

- reply

My thought is nostr is novel, that’s central to it, but we’re burying it behind non-novel, familiar interfaces

2023-01-28 22:08:51

- reply

I think all of this can be done with new user models.
Users understand things like ‘rooms’ , ‘urls’ etc
They can understand relays

2023-01-28 22:07:30

- reply

This is only true because clients hide relays. If clients made relays first-class, you’d know ‘where’ you were, you were posting to and reading from in different contexts.

2023-01-28 21:44:15

- reply

Fair point.

2023-01-28 21:43:57

- reply

Damus recommends relay sets, will soon effectively default/auto-pilot relays.
Where this devolves to is most of user base will have no concept of relays, “I’ve got my client and there’s some backend something out there cool I’m on nostr f the system” - but which devolves into every other standard social platform out there.
Yes we have “portable” identities but I’m not sure portable keys model saves you here … for all intents and purposes.
The nostr vision as I initially read it was relay-centric. This seems to go the opposite way entirely.
Maybe I’m overstating all this.
But we’re in prime early phase here and this seems the time to really embrace the core nostr model not hide it all.

2023-01-28 21:20:04

Relays have become full blown shameful at this point. Long live nostr.