aaron
A. A. RON

Hey I'm at a modest 3000 GB/month, but I can't justify to my family spending more of our own money.
> Why use a master and not just sync between peers?
I think this may be more ideal, I had a thought about needing a master but don't recall what it is. I think nostr protocol needs an addition, however, to "ack" writes so that clients can know for certain a write is durable.
> What is the logic of when to redirect reads? If daily/hourly egress is exceeding a plan?
Peers would say "I don't want more work right now" (for any reason they like) and then some coordination strategy would have to "balance" over peers that are happy to take work.
> Why not just drop a new connection under the same circumstance to force the client to use another relay?
Dropping connections won't work. There needs to be a first-class understanding of how to get "all" of the data you are intersested in. So you need a single relay endpoint (relay url / "brand") that coordinates across peers and ensure complete data coverage (for whatever that means for the the relay).
Sharding is less about disk space (b/c disk is cheap and you can archive older data etc). It is more about solving the network egress - but putting more burden on the client level. So client is responsible for figuring out which shard or shards to go to with for any given query. Haven't thought about this direction much, though. For global timeline, every shard has to get hit in this world, so that is not great but more thinking could go here.

2023-01-14 04:32:46 UTC

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-14 03:27:43 UTC

- reply

No at that point your phone itself will be Damus

2023-01-05 00:01:09 UTC

- reply

Do you see a lot of limit-less firehose queries? I’ve been thinking about auto-limiting users/clients that request the same big query repeatedly.

2023-01-04 23:40:30 UTC

- reply

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

2022-12-22 19:53:27 UTC

- reply

I might move to support https://github.com/nostr-protocol/nips/blob/2fa78a8097745139be5299c9f6117049f7d4a074/22.md but only restrict far-future events. At the end of the day, though, I don't see how clients can't avoid having to deal with future events....

2022-12-19 13:00:27 UTC

- reply

what latencies are you seeing?
my tiny relay is holding up decently but I’ll prob need to upgrade the machine soon

2022-06-09 15:42:40 UTC

- reply

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

2022-03-21 01:35:19 UTC

I’ve been on vacation. What have I missed in nostrland

2022-03-09 04:00:51 UTC

- reply

👍🏽😎😎😎

2022-03-09 02:23:29 UTC

- reply

beautiful; i wanna use this beast, how do i

2022-03-07 21:18:24 UTC

- reply

Nice!
Wonder if I should try some first class support for this
If user tells the client that an event represents a room then it can give a separate chat experience that’s more like Slack/telegraph
Keeping the lists out of the customary timeline

2022-03-07 17:11:30 UTC

- reply

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

2022-03-06 21:42:49 UTC

- reply

You're not deep.

2022-03-06 21:39:48 UTC

- reply

Similarly deep.

2022-03-06 21:39:34 UTC

- reply

Deeper.

2022-03-06 21:34:36 UTC

- reply

Sna

2022-03-06 21:21:21 UTC

- reply

Nope.

2022-03-05 20:35:02 UTC

- reply

(i just pushed the first version of publishing to repo -- no reply ability yet)

2022-03-05 17:50:51 UTC

- reply

- on left you can add many identities- one will have focus and you'll see its timeline
- rn the whole thread is shown in the timeline - and a thread is sorted into timeline by its latest reply
- the end-to-end latency is fast!
- all ux & ui decisions are open for critique

2022-03-05 17:46:33 UTC

- reply

https://giphy.com/gifs/nostr-kAKrd92lIX5gC6t9Wh

2022-03-05 03:52:16 UTC

So fast.

2022-03-05 03:50:27 UTC

First message from desk client.

2022-03-04 03:54:19 UTC

- reply

Timelines show full threads right now. Would love for someone that can do pretty styles to give a pass. The styling is roughly css, but javafx style.

2022-02-24 00:58:01 UTC

- reply

👍

2022-02-23 03:53:59 UTC

- reply

https://github.com/atdixon/me.untethr.nostr-desk -- not usable yet
if want to try: -- start it up per README, then manually add public keys to `identities_` sqlite table in `~/.nostr-desk/nd.db` then restart
all read-only so far except you can edit relays (click low left)

2022-02-22 14:27:04 UTC

- reply

been hacking here & there for a few weeks, whenever i can squeeze in some minutes, i will push it up to repo next chance i get

2022-02-22 03:56:12 UTC

a so far ugly cross-platform nostr desktop client https://media.giphy.com/media/Bw8ZmPkUVliQpcUvaK/giphy.gif

2022-02-21 02:43:00 UTC

- reply

right

2022-02-21 02:42:47 UTC

plank

2022-02-21 02:39:59 UTC

Sup

2022-02-19 03:52:05 UTC

- reply

Ship

2022-02-16 22:41:56 UTC

- reply

Sha.