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-04 20:58:24

- reply

lnbc100u1p3aawxtpp53t92g4mx26f3r87pth56u4sycf6q3uhv4tqmna5qld5wmk5ec8jqdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5fnquxuz3v94hce4vehrxrx62qlfntyuzk5d9e92jfruac2sg9ucs9qyyssqrs2aljruadqpkgjdlz2lwnne4emw26j7yrjnpc44nw8lv2rldy9rltmy8cu7ma9s6qk3wqshtfefx7fm957v0e046e6uup8fvwt0zaspzwfytx

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 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 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 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-03 23:59:01

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

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

- reply

wss://nostr-relay.untethr.me

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 01:58:35

- reply

c=3

2023-02-01 01:57:36

Pick your relays. Don't acquiesce that power.

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

2023-01-27 02:08:32

Global Roulette

2023-01-26 00:54:40

Ping : Ping :: Test : Tost

2023-01-25 23:45:55

What does https://nostr.watch/ say is your latency for wss://nostr-relay.untethr.me?

2023-01-25 23:00:44

- reply

Similar.
I've been thinking about rewriting queries like this to consolidate them (and be somewhat more efficient) when they can be.
This works with "authors" because no two events can match the same author, but it doesn't work for other queries.
For example, [..., {"#p": ["a", "b"]] and [..., {"#p": ["a"]}, {"#p": ["b"]}] are not quite the same.
#[6] you are probably getting away with UNION in these cases and letting db engine do the de-duplicating for you.
But once you implement cursor/"pagination" of queries, leaning on UNION for deduplication won't work.
I'm doing pagination/cursor-based query results now, which means you might get duplicate events in some cases for a separated "#p" query like that.
However, once I implement query rewriting this will be partially fixed by rewriting [..., {"#p": ["a"]}, {"#p": ["b"]}] to [..., {"#p": ["a", "b"]], which will be more efficient and naturally produce non-duplicate results.
For query filters that can't be consolidated -- e.g., [..., {"#p": ["a"]}, {"#p": ["b"], "authors": ["dead"]}}] -- deduplication is kinda tricky and not ideal, so will have to figure that out at some point or live with it.

2023-01-25 04:04:53

- reply

You need a vanity pubkey to get good support.

2023-01-25 04:03:20

- reply

I would think it’d be an external service that clients query.
And think of it as part of the client/experience, not as protocol/relay.
I think search/discovery as another thing like this.
But this is personal opinion.

2023-01-24 05:15:14

- reply

Nice tip! How do they get away with that? Is that limited time?

2023-01-24 05:12:21

Interesting. First time I had to start manually adding & hopping around relays to read/resolve a whole thread.

2023-01-23 03:41:13

- reply

It would be my relay if you’re connected to it (wss://nostr-relay.untethr.me).

2023-01-22 18:19:43

- reply

Yeah! This is the idea. In my relay code each websocket connection gets its own arbitrary state ("session") object. So the connection path would mark the session, and from there the handling of any nostr `REQ`(subscription) or `EVENT`can just follow whatever rules are appropriate for the path. Possibilities are endless really.

2023-01-22 04:39:21

- reply

Much like email clients - but social is different…maybe only because we’ve been primed that way to date.

2023-01-22 04:38:27

I've been thinking about implementing "virtual relays" in untethr.me code.
They would go like this. In your client, you would configure your relay to: `wss://nostr-relay.untethr.me/virtual/<any-string-you-make-up>`.
Then this becomes a silo, its own relay: only clients configured with this relay will see data from clients configured on this relay. (Unless of course someone consumes a message and publishes it again at the root relay or anywhere else.)
This will be really easy to implement efficiently (w/ no extra overhead) within the current relay code.
I'm not sure what clients do if someone were to configure multiple ones of these -- i.e., if a relay URL resolves to the same IP address. (Hopefully they just respect them.)
There are other variations of using URL paths to change behavior. For example:
`wss://nostr-relay.untethr.me/read-only`
`wss://nostr-relay.untethr.me/write-only`
`wss://nostr-relay.untethr.me/reactions-only`
...etc...
You get the idea.
Thoughts?

2023-01-21 00:32:25

does damus AUTH

2023-01-19 04:41:17

nostr are you going to give me a 3-month lead on the next pandemic like twitter did?

2023-01-19 04:00:57

Sir, this is a bitcoin chat room.

2023-01-19 03:59:18

- reply

5000000000 sats isn’t code for something is it?

2023-01-19 03:21:58

Tell us your age by mentioning the first nostr client you ever used. I'll go first,
branle

2023-01-18 19:36:59

- reply

Ah I see it used to be a spec
I think kind 6 is reserved at minimum at this point then

2023-01-18 18:36:07

Who sends kinds 6 and 70202? (Both of which I’m dropping atm.)

2023-01-18 03:27:28

- reply

Hmm where to
Nips github issues ?

2023-01-16 19:41:52

- reply

Probably good practice to change your mind even when the facts don’t change.

2023-01-16 03:33:45

- reply

Anything with David Spade

2023-01-14 21:46:03

- reply

Yeah, agreed generally what you're saying. I'm doing this for fun. I wouldn't be able to develop the relay code I'm working on without actually operating a relay with some kind of load, so I'll put a cap on connections or data some point like others are doing.

2023-01-14 04:54:45

- reply

It would be from relay -> client

2023-01-14 04:27:43

- reply

No at that point your phone itself will be Damus

2023-01-14 04:16:11

- reply

We need batchman