aaron
A. A. RON

Public Key

npub14lu6nuqh7v4jazmqw49yzqkmnkw0nletjeuqfdgwqurcp2j9ex5qz37m8m

Profile Code

nprofile1qqs2l7df7qtlx2ew3ds82jjpqtdem88elu4ev7qyk58qwpuq4fzun2qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uwe4m6e

Publishing to

relay.damus.io

eden.nostr.land

Author Public Key

npub14lu6nuqh7v4jazmqw49yzqkmnkw0nletjeuqfdgwqurcp2j9ex5qz37m8m

Show more details

Last Notes

2023-02-07 00:26:47

- reply

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

2023-02-03 03:49:18

- 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 01: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-01-31 23:47:12

- reply

wut

2023-01-31 01: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 01: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 01: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 01: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 02: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-29 23:18:26

- reply

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

2023-01-29 23: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 22: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 21: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 20: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 20:20:04

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

2023-01-26 00:34:02

- reply

Right!

2023-01-26 00:33:08

Someone build del.icio.us on nostr

2023-01-19 03:00:57

Sir, this is a bitcoin chat room.

2023-01-18 17:39:08

- reply

Please add
https://github.com/atdixon/me.untethr.nostr-relay
🙏

2023-01-14 04:32:46

I’m not going to be able to afford much more monthly egress from my relay. So I’ve been thinking about out how a relay peer scheme would work.
Ie instead of all of us running silo relays, some of us could peer together.
In one version of this peers could redirect *reads* to a less overloaded or under budget peer. Writes would have to route back to a master and maybe to other interested peers. The master has to replicate to peers, but that would be less egress presumably than serving all users.
The ideal would be to have a lot of peers but no more so that any given relay is cheap and the master a little less so.
This version probably doesn’t need protocol changes at all.
In a separate version clients could get involved and hand-wavy you could split/share data across peers that agree to be part of a group. But you’d need a way for shards to drop in and out.
Any of this been discussed at all? Any ideas worth pursuing here?
#[0] #[1]

2023-01-06 01:33:45

I’ve picked up some new Twitter follows from here

2023-01-04 23:40:30

- reply

😎 how many active users? do you fulfill limit-less subscriptions fully (i.e. all of history?)

2022-06-09 15:42:40

- reply

https://github.com/ACINQ/secp256k1-kmp -- fme way faster than pure JVM impls

2022-03-07 17:11:30

- reply

But anyway- wonder if there has been thought to replacing Telegram w/ first-class nostr client?

2022-03-07 17:11:05

- reply

Only consequence is that your followers will see all of your chats in the room unless your client elides them. (Not sure what it could use to decide to elide them...without introducing some new nip/rule.) 4/

2022-01-30 18:25:06

- reply

Dang

2022-01-30 15:05:21

- reply

Pong

2022-01-30 15:04:35

Ping.

2022-01-18 22:25:04

- reply

looks like the initial REQ from nostr.rocks doesn't include a since - and relays are providing every event since forever each time?

2022-01-18 22:14:21

- reply

i'm wondering the same thing