Nostr Web Client

I value order, efficiency, and reliability. I don't value simplicity or chaos quite so much. My effect on the nostr protocol has mainly been proposals to improve the reliability, efficiency, and orderliness of it, and the pushback has come mostly from people that like the freedom that the chaos gives them.

Some examples

* long ago I proposed that relays remember when an event arrived, and clients could query "all events that arrived after I last asked" to get a perfect next batch.

* long ago I proposed gossip/outbox model which specifies where events are expected to be, while many still choose very different and innovative ways to choose and use relays.

* I've been pushing for DHT usage to be more fully distributed and uncensorable, and to allow people to kickstart/bootstrap without knowing any relays or any nostr people. We get 99% functionality without it and so as you could imagine other devs don't really embrace the idea. I'm the guy who is never satisfied with 99%.

* I've wanted a rigorous standard that doesn't change

* I've wanted a binary protocol to juice up efficiency by avoiding JSON parsing

I feel like the black sheep in this regard (hence my avatar) because I gather that most nostr developers (and users) more highly value chaotic liberty.

Chaotic liberty is a great space to innovate in. But it is not a good space to build a solid user experience which requires a firm standard and compliance for interoperability. Hence I see hundreds of only somewhat compatible half-ass nostr applications that generally scare users off (which one? why are so many of them broken? and so different?).

This is all fine. But it means I'm not seeing nostr as the protocol that becomes the social media framework that the Internet eventually adopts. I see it more and more as a playground. Which is critical and innovative and wonderful. I just don't see how it can also be a stable user experience that draws in lots of users and creates substantial network effect value.

Mosaic is where I scratch my itch for order, efficiency, and reliability, and my attempt to create a solid user experience. I will be working on both Mosaic and nostr. Mosaic risks being too idealistic, the "betamax" of social media, but it is a risk I'm taking. Take joy knowing that I won't be bugging nostr devs as much about the chaos.

Should I post this or edit it more? Fuck it. I saw a meme that said to just post it.

Reply to this note

Please Login to reply.

Discussion

HoloKat 6mo ago

I’m guessing the format for this sort of discussion is not the right one. There’s no guarantee any significant number of developers see your note or have enough time to consider and reflect. A nostr developer call or something of that sort would get more attention to issues you and others bring up and the proposals around them. Are there even any nostr dev calls or meetings besides client-specific calls?

Mike Dilger ☑️ 6mo ago

To your question specificly, I'm not aware of any organized nostr development meetings or chatroom.

I wasn't trying to start a discussion, I was just reflecting on and expressing my thinking. I'm not asking nostr devs to be different, nor am I informing them of anything they need to know.

I do plan to explain Mosaic to the nostr community, and ask for feedback and general comments on what I"m doing and if I'm a bad sheep. But I didn't want to waste people's time with something that I'm chopping and changing a lot still, so once it is worthy of people's time to be reviewed, then I will try to get it onto more people's radar. It isn't hidden, it's all open source on github, and I'm starting to mention it casually here and there so that those early adopter types of people can do their early inspection of the thing if they want to.

HoloKat 6mo ago

Alright. Maybe I’m mistaken in sensing some frustration - for which I thought there might be a better forum for proper consideration.

Mike Dilger ☑️ 6mo ago

Ah I see. I'm not frustrated. I just feel more aware now of why different devs push for different things and I felt like sharing that.

Tekkadan, ゲロゲロ! 🐸 6mo ago

> the nostr community seems happy with JSON, with websockets, with a single key using FROST remote signing, with finding relay lists on "popular" relays, with relays using URLs not keys, depending on CAs and DNS, outbox model being optional, AUTH command ordering issues, kind1 vs kind1111 issues, the notion of relays being front-and-center in user's minds is debatable (I think they can and should be mostly hidden magic), the fact that every relay is deeply different and there is almost no way to know what you are getting. The simplicity ethic I feel is taken too far. And the just one-way rule. NIP-11 out of band is a pain. Endless stream of breaking changes.

Disagree. I think most users are not developers. What you're describing is architectural. Few people aspire to be network architects, especially not for low-level grant-based funding, especially not in JSON spaghetti net land.

Forking the protocol is healthier than pretending this iteration will thrive at scale.

Testnet nostr was not a failure. It is simply a stepping stone and a learning exercise. There is inherently a lack of collective direction. To find something new and interesting that works without conflict would be exceptional, not a threat. People want to move forward.

In the end, software should be FOSS and collectively-enabled. We have agreed that we want to be here- ask yourself why that is. The answer is partially gif buttons, nip-25, dm's.

The other part of the answer is good architecture to support the millions of ways people use the internet, and how to intricately weave them together.

Produce something you actually desire to use in your daily life and work backwards. 🧑‍🔧

Should I edit this or just post it 🤔🧐

Mike Dilger ☑️ 6mo ago

Yeah I guess when I say "nostr community" I didn't mean that. I meant the nostr developer community. So I agree with your disagreement.

fiatjaf 6mo ago

What do you think of going full p2p with iroh instead of using relays? (Assuming it works.)

I mean, if the idea is to ditch Nostr to something more idealistic and more "correct" than that path should at least be considered. Relays were the Nostr compromise to make things "work" because p2p has never worked in practice (in theory I also think it doesn't work), but the iroh people swear it works now, so who knows.

One problem with pure p2p is that people have to keep devices online, but that can be solved with adhoc "relays" which are actually just nodes -- you eliminate the distinction between clients and relays and just query nodes for stuff, people can nominate other nodes (identified by public keys just like their own devices) to host their stuff while they're offline.

Another problem with pure p2p is that you don't get discovery of new content, you only fetch stuff from people you already know -- but again here we can defer to these adhoc relays to curate and host content from others and you can call these to download stuff and expect to get back quality content from people you don't know, and maybe you'll start following these people.

Mike Dilger ☑️ 6mo ago

That thought had crossed my mind multiple times. I think it is definately something to explore. I mainly see relays as having an expectation of uptime, whereas p2p tends to only work if your computer is on right now. But clearly people can also run servers behind NAT. And as you say, people can use servers not behind NAT (relays) to solve all kinds of problems.

I'm very open to this and I don't have any firm beliefs about it yet, so I'm impressionable and you could steer me quite easily right now.

Mike Dilger ☑️ 6mo ago

Also, I really like the choices the Iroh guys made (rust, quinn, QUIC, even BLAKE3).

When I tried using Iroh, it worked, but it was going through their stream relay (they have 3 relays I think worldwide in case holepunching fails).

I'm also a bit concerned that Iroh is a software stack, not an open specification, or at least that there isn't a separate alternate implementation.

Tekkadan, ゲロゲロ! 🐸 6mo ago

https://rsocket.io/ ?

Daniel Wigton 6mo ago

Hmm. I feel like we have all the right ingredients. We just need the right team. I've been mucking with a spec for 8+ years and every time you open your mouth, I raise an amen. This indicates to me that, given the convergence of ideas, there is a correct answer.

The problem is that everything needs to be fixed at once. There are lots of pre-existing projects that are mostly correct for some aspect, but this is a case where mostly correct doesn't get you there, largely because the pre-existing solutions over solve some aspect making them, as you mentioned, software rather than a spec.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

i think that mistakes were made but the core principles are corrrect.

i am working now on buliding relays as multiple components, so, the spec has many things, and some naturally cluster functionally, and other things are able to be separated.

i'm currently rewriting realy to be a bare naked unauth simple relay, and then i'm going to build a relay auth proxy, it will be set up between the client and the relay to control access, thus simplifying the build of both parts

the same thing could then be done at a third layer with network transport, giving you a p2p type networking

i can think of other layers to add too, like proxy caches, that are dumb and can only comprehend "do you have event ID X" - sorta like blossom but basically nostr query only for event IDs, or for pubkeys, or for the newest thing.

actually, i started building something inspired by chatter with semisol, an HTTP API call that lets you just poll a relay for its internal reference numbers (monotonic sequence numbers of each event) and a peer then only has to keep a latest sequence number state value related to another relay and the relay can then deliver all the newer events to it no muss no fuss.

i do think the nostr protocol has a load of ugly bits in it but so long as everyone mainly respects the nip-01 rule about string escaping i'm good. all the other things are copable.

Daniel Wigton 6mo ago

It is my long term goal to eventually convert you to something a bit lower level than nostr. Years from now once I finish this spec and a rust reference implementation, I won't be happy till someone makes competing implementations in other languages.

We are probably all a bit too curmudgeony to ever work together, but we'd make lovely competitors. Flame wars and such.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

yeah, i want to remove kinds, and json, and websockets. tags can do kinds, line structured text is simpler to parse and easier to read for humans, and http/sse serve perfectly fine, modern network stacks don't need liveness pings to report tho the client or server that the connection has dropped.

shame about the language tho. rust is ugly, and overly complicated, unlike what you are trying to achieve.

Mike Dilger ☑️ 6mo ago

Nostr has a lot of bright devs that could all work together to build the next iteration. I certainly don't have it all in my head. I've focused on the low-level stuff, and other devs are far more aware of the problems with the nostr high-level stuff. For example, if you asked me how zaps should have been done, I have no idea. But of course among the low level stuff we have a lot of different ideas and thoughts. I'm keen to dig into other similar work like nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku realy, dpc/rostra, iroh, nostr:npub1l3cgtsurhfchg4cyhhqudm70074sr96srhje330xc5m6czej5n9s9q6vs2 spec fork, any spec you are working on, etc, and try to pull the best stuff into a consistent spec. I was intending to finish Mosaic and submit it as "this is how I would do it" and then tear it to shreds with the feedback it got. I only made it detailed to prove to myself that the ideas would work (in that proof I have changed them quite a bit so it was worthwile)... even though that seems wasteful to get so detailed so early without feedback yet.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

if someone can come up with a plan for migrating to a new wire encoding that would be great. i've thought about it. mac users might be familiar with the concept of "fat binaries" and i can imagine a new format that includes the old message in the old format also signed as a transitional step, that allows a relay or client to propagate messages that a transitional client or relay can recognise and know to extract the encapsulated message for legacy clients,

ultimately eventually deprecate the json encoding. my feeling is to use line structured, sentinel based, and we need to get rid of kinds because they are redundant if you can wrap them into tags anyway, and the escaping scheme of json, ok, nostr has a simplified one that only has like 8 escaped characters but you can trim that down to two if you use linebreaks as separators of event fields.

i also think that websockets are a dumb idea, all of the functions can be done without sockets. SSE covers subscriptions and you just open one to a relay to get push messages and everything else you send http requests.

i was going to build out a protocol i was provisionally naming "manifold" using that line structured encoding i mentioned, but i decided to switch gears and build a layer cake relay where you have the core nip-01 (and maybe eventually add delete, search and a few other things that kinda fit within that box) and then wrap that in a proxy that does the nip-42 and can also handle nip-98 auth as well, and a yet to be defined authed proxy protocol that allows a client to get a relay to proxy content fetched with their authorization from auth-required relays.

Mike Dilger ☑️ 6mo ago

I like the fat binary idea. Newer clients sign the JSON event and also the new format. Mosaic has been going with a "clean break" and a new cryptosystem, in which this idea isn't sufficient for dealing with replies... but I'm getting closer to the point of just accepting that we simply have to stick with secp256k1 and simply have to keep working with existing nostr.... still a fight goes on in my head.

Line structured data (like HTTP) is reasonable. But even HTTP after they went with line-based added compression. The compressed data is clearly binary, the thing everybody shutters about, but nobody seems to mind when HTTP uses compression. I also want what is digitally signed to be all lined up ready to sign and not need to be copied and shuffled first, but that is a minor point.

As for kind, I'm of the opinion that we have a 64-bit kind number, where 5 bytes are the application ID, 2 bytes are used within the application, and 1 byte is flags telling the relay how to handle it (ephemeral? duplicates? serve only to author? etc). Then applications (like zaps, kanban boards, git, etc) are out of scope and specified by anybody who wants to write an app that is now strictly on top. App IDs are just handed out to anybody who wants one with no debate.

HTTP/WebSockets doesn't add anything on top of streams except for framing (which is easy). So I'm for direct on top of QUIC, and for Tor support which can't handle UDP direct on top of TCP with TLS.

I'm keen on using client-side certificates in TLS for auth. The only downside is that your connection is either AUTHed or not, so you can't conditionally upgrade it, meaning you have to reconnect if something let you know it is time to auth. But reconnecting on QUIC is trivial and highly performant. Putting AUTH inside of nostr caused some state and order related problems... maybe we solved them all I'm not sure. But TLS auth I'm quite sure is well researched and secure.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

personally i like BIP-340 secp256k1 signatures. but the simple fact is that they are basically the same as ed25519 except with a group that has a couple more roots than 19. even the modulo multiplication of signatures is almost identical, basically schnorr. which was technically out of patent when satoshi dealt with it. and also, secp256k1 and ed25519 are both "nothing up my sleeve" curves and what's better about the bitcoin curve is you can use the exact same group to do ECDH where you have to use curve25519 to do ECDH in edwards universe. which is a problem.

compression should really be considered to be a transport layer thing, what is received by the client should be the uncompresssed binary anyway.

we don't need kinds. that's what tags can be used for. and we don't need multiple value fields, because the only reason why nostr has multiple fields is because of the "only single alpha character is indexable" idea. if you throw away that silly idea, then you see that kinds becomes a tag, which simplifies the database indexing and simplifies search notation as well. and it also means we can use standardised mimetypes, like email and http.

i like quic too but i think that for mostly non-interactive stuff it's a waste of time using sockets. you have requests, and you have push on the other side.

it would be zero change to most code to enable listening with quic protocol and connecting with it as well. and since it's all http, it could be in the headers to request transport upgrades other than websockets, like quic, i think that's already pretty much standardised.

TLS auth basically works on the same principle as nip-42, nip-98 and JWT anyway. signature, timestamp, challenge.

i thought you might appreciate my counterpoints on those.

i'm not against edwards curves at all but the support for ECDH to do symmetric encryption is very clumsy right now in comparison.

Mike Dilger ☑️ 6mo ago

My interest in ed25519 isn't really the cryptography technicals. You make a good point on that. I'm only interested in wider compatibility. You could use ed25519 within TLS, or to store bootstrapping information in bittorrent's DHT, or even as OpenPGP keys (or openssh, or wireguard, etc). But you can't do any of that with secp256k1 (why? probably no good reason but they just didn't add it).

The difference between kind being a tag and kind being a separate field is that when it is a separate field it is required. As a tag it might be left out. And I think it must always be specified. So long as it is always specified, how it is encoded doesn't seem to make a functional difference. I'd prefer a separate field so it is never forgotten. I've written database indexing at least 3 times now on the KV database level. You are right it would simplify it without a separate kind. And the filter would be simpler to just have tags and not a separate kind. But I still think it should be separate for reason I mentioned.

I'm good with standard mime types. There is the concern that if lots of mime types are used, clients wont know how to deal with many of them. But I think that is workable.

QUIC is really just a reimplementation of TCP+TLS. HTTP/3 is built on top of that. Request-response HTTP (1.1 or 2.0) is built on top of sockets itself, just the spec closes it down after the server responds, instead of leaving it open for more messages later.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

from a database implementation perspective, the kind field creates an extra factor in a factorial combination of fields that the user can search on, that's why i want to do away with it.

kind specifies a protocol - the combination of an application, and an encoding, right? all messages need this anyway. mimetype: text/plain would be all you would need to describe kind 1 notes. other things might be more complex, like long form, you would want to have text/markdown or text/asciidoc or text/pdf or something, but again, you would have to put these somewhere anyway, it's not like it would be logical to leave out the document type. most event kinds are just document types, some include encoding, some include application/protocol stuff.

so, i'm just saying, kind is mostly redundant, and even already some event kind specs already are redundant by having a kind, as well as these more detailed things in the tags that are part of the kind definition.

65536 possible encodings/document types/applications is very restrictive and not at all future proof.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

also, regarding quic, and TCP itself - this is for short message interactive protocols predominantly. not even as slow as IRC chat messages, faster than this. think collaborative document protocols.

for threaded forums, completely useless and irrelevant

for chats, pretty much not relevant to use this kind of low latency interactive socket transport

it's only for control interfaces between servers, really.

i mean, sure, there is no problem to use HTTP/3 over QUIC transparently in many languages already anyway. i think it should be just negotiated in the http headers, or better still, different ports/schemes (same thing, really).

Mike Dilger ☑️ 6mo ago

Couldn't you just have a tiny translation layer where you move the kind into the tags before you do the indexing, and before you do the searching by filter? That is, index the kind in the same index that you use for indexing the tags. Maybe make the tag key something unique and nutty like7SFOIU_l, to avoid collisions.

I think kinds have a lot more meaning than describing how to interpret the content. They imply how to find the events you care about (e.g. outbox model?), if replies/threads make sense, if they are ephemeral, multiple versions or replacement, and maybe much more. I wouldn't want to presume we know all the other things kind might mean in the next new innovative idea. It provides hard separation between very different application types, which I very much like.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

well, you'd have to interpret the meaning of each kind to decide how they would be tagged. some might be one, some two, some three facets of the design.

like what nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z has been doing building indexes and document segments has done with several types, there is a case of several kinds that are really part of one document.

and in other cases, kinds can actually pertain to several kinds of documents, all connected to the one kind, but they have several formats related to them.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

yeah, simple example:

kind 1 events

you have the root second field in the tag for the OP

you have the mentions (p tags) that point to past known events related to the thread

so, you already have two distinct types of documents in the kind 1, the root, and the reply type.

then, additionally, you can also refer to these in other 1 events that are either root or reply kind 1s, that refer to other kind ones, called "quotes" and "reposts".

Mike Dilger ☑️ 6mo ago

We are imagining different things. I'm trying to build an isolated layer wherein the content is opaque, and there is a kind that specifies whose social media specification protocol this record belongs to. If someone wants mime-multipart content or whatever, that is the next layer up from what I care about, opaque at the layer I'm concerned with. Now if any application has specific needs from the lower layer and they are general and apply to multiple applications, then I need to think about that.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago

kinds are not a singular thing, and they are not descriptive. they are a stupid number that tells you nothing and forces you to refer to some document that probably will change and refers to applications that are still alpha.

what the programmer who is building tools to generate and parse content needs:

1. encoding

2. semantics

3. protocol sequence

kind is all three of these in one, cloaked in a stupid number, and hosted very often inside a PR on a poorly managed specification repository. it's not descriptive, it's just cryptic.

arthurfranca 6mo ago

Using just ws:// for both one-off and live communications and the Nostr event structure being JSON sure attract devs. This part isn't the problem. (Though, why .content isn't a regular tag? Why is .id included?)

Regarding nostr keys/signature/structure, if changing them wouldn't make things so fast that a new use case would be possible, I guess it isn't worth it. And its good to have something like frost available.

But Nostr has some annoying inefficiencies on relays that won't ever change cause it would take additions to NIP-01 that, let's face it, will never be made.

The main inefficiencies are:

- The relay can't apply different event size restrictions by event kind on EVENT messages. Using a ws binary message with the event kind at the beginning for that would be great.

- Why is sending the event id (client-to-relay and relay-to-client) required when it would have to be recalculated anyway to make sure its correct?

- Relay can't announce it's custom features/config within the ws connection: https://github.com/nostr-protocol/nips/pull/1969

- The AND operator won't ever make it to NIP-01 (new NIPs can't use it for new event kinds cause relay support would have to be broad): https://github.com/nostr-protocol/nips/pull/1365

I guess if someone has the time and willpower to invest into making a nostr-v2, they would have to spin-up a big nostr-v2 free relay to attract client devs and index events from v1's main relays to have initial content. Good luck for that brave guy or maybe this will be Google or Meta at some point.

arthurfranca 6mo ago

damn Coracle bizarre threading ui

I replied to a msg a bit deeper on the thread than I wanted =s

Daniel Wigton 6mo ago

I think this is the way. You can get to a kind of Facebook like experience. Seeing content from people you know. You do trade off many things like broad discovery, but what you get in return is a network that is extremely resilient to outside censorship and hard to spam, even without filters.

The reason that it should be done is that, even if it isn't very performant you do get something that is 100% aligned with the users.

From there you can add more robust nodes to people that better uptime / wider reach. That will have some centralizing effects, but if those fail then ordinary people still have a fallback that doesn't make them susceptible to all the problems of a wide open relay.

Mike Dilger ☑️ 6mo ago

Imagine that we created a way for relays to live behind NAT and be hole-punched into (using Iroh or otherwise) but they were still separate from clients. Then imagine we forced every client to also be a relay, and conversely every relay to also be a client. Do we then end up with the circumstance you are envisioning or have I missed something?

Because in that scenario, while I like the 1st step, I don't see the point of the 2nd step. it seems more flexible to leave relays and clients separate.

Daniel Wigton 6mo ago

A mix of the above. You might run a client/relay on your PC, but they are sort of different concepts.

You might have a node that just distributes files having no idea what they are. They are just identified by their hash, but may be compressed and encrypted.

You might have a node that is just a proxy for establishing connections.

But what everyone has is at least one node that stores their own files/stores their keys/can do authentication/encryption for various application/clients.

If you only have a phone then I guess you just accept that it isn't going to be a great experience/lean on the hardware of friends.

Matt Lorentz 5mo ago

SSB without the hash chain? I'm down.

Matt Lorentz 5mo ago

Surely someone has built this, right? Why haven't I built this? 🤔 questioning everything.

ynniv 6mo ago

I tend towards my take on "firmitas, utilitas et venustas" for software: "safety, correctness, efficiency". I think when developing for nostr that "worse is better" – eg, to purposely avoid optimizing for efficiency because that requires tradeoffs which are easy to overlook.

For instance, XHTML never took off because, even though there is value, it isn't attainable without global consensus and there has never been consensus on what constitutes valid HTML. From the engineering perspective this can be infuriating, but from the user perspective they just edit text and much of the time

It works!

It's better to be useful than perfect

Mike Dilger ☑️ 6mo ago

You aren't saying XHTML was the "efficiency" option, are you? XHTML had lots of problems, XML and DTDs being just the beginning. I was very much on the html5 side.

Yes it is better to be useful than perfect and I don't think I'm aiming for perfection.

With binary protocol it really was just because nostr events have not changed, and so it's no longer too early to optimize.

ynniv 6mo ago

Hah, no, XHTML wasn't an "efficiency", but you're also asking for a rigorous standard.

I'm still against a binary standard. It makes novel clients much harder to write, and the fundamental gains are small. I've personally written code that completes an HTTP POST with a JSON payload in less than a millisecond... if you want performance there are ways to make that happen without locking out casual developers

Mike Dilger ☑️ 6mo ago

TCP is binary. TLS is binary. QUIC is binary. Casual developers are not locked out of them.

If a developer is casual, they won't care about the binary details. They will just call a function and get a JSON blob out of it. I think the insides can be binary and the API can be JSON and we can have both.

ynniv 6mo ago

No application binary implements TCP. I can assure you that only environments with an SSL or QUIC library will ever use those protocols. Maybe nostr is necessarily the same because of event ids and cryptographic signatures? It's possible, but I'm not immediately convinced

Anthony Accioly 6mo ago

I'm with you on the whole "organising Nostr chaos" thing... That's basically what I try to do as well. Much less successfully than you, though, as I don’t even propose a lot of stuff... More like try to fix existing standards and tooling in a minimal way.

Still, I care about a lot of the same things as you. Actually, I care to the point of pestering you multiple times about the NIP-05 vs NIP-65 bootstrapping ambiguity, and pestering, well, just about every dev on Nostr about implementing proper Outbox model support, leveraging DHT to avoid centralisation on the bigger "indexer" relays, sending the right kinds to the right relays, supporting NIP-17, NIP-29, etc., etc., etc. I also like the idea of more formal contracts, and possibly evolving beyond signed JSON over websockets.

I think a lot of devs on Nostr are thinking along similar lines. We (or at least I) just lack a good way of reaching out to each other. I don't have a "Gossip" or "Nostr bootstrapping" forum to reach out to you, no NIP-29 group, no IRC, XMPP, Matrix or whatever that I can join to discuss this kind of stuff. I’ve got too many notifications on GitHub to even bother. And as much as I love pestering fiatjaf, Vitor, etc., there’s only so much that can be done via Kind 1 or DMs theis way. I think if we can put some effort into organising communication channels beyond PRs and comments, we’d stand a much better chance of driving this kind of effort forward.

I don’t know much about Mosaic, but it sounds like a heck of an interesting greenfield project. All greenfield stuff is amazing, beautiful, and promising. Nostr has this “ever-greenfield” attitude, which I totally get. But the fact is, there’s already enough "legacy" on Nostr. We need to start managing it like every project that’s survived a couple of years beyond MVP. Get the communication structures in place, and the right people will come together to drive the architectural changes you’re looking forward to.

Mike Dilger ☑️ 6mo ago

I'm not sure if a chat forum like xmpp/matric/irc is better than kind-1/1111 for this. I like the threading here. But more idle temporary chatter could be good too. nostr chat isn't half bad, there must be a room for this and if not we must make one.

Mike Dilger ☑️ 6mo ago

or maybe it's on telegram and I should reinstall telegram.

Anthony Accioly 6mo ago

The problem with Kind 1 is that a lot of people in other timezones won't read it.

I've tried Kind-29 and managed to lock myself out of my own community lol. Also, I haven't felt a lot of enthusiasm from other folks to play with NIP-29. 0xChat Signal like LMS stuff sounds exciting. nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp0g4rts7 is also working on a Slack / Discord like thing with Flotilla, but it's still at early stages.

I'm happy with whatever tech you folks pick, Nostr or otherwise (although I would prefer Signal to Telegram and XMPP, IRC or Matrix to both of them). But lets start creating those groups/ channels somehow. It has been hard to keep up with what all of you folks are up to.

Mike Dilger ☑️ 6mo ago

We used to talk on Telegram. One day I burned my account because I suspected Ukraine was using it to crash my computer (only because of the repeated coincidence of when it crashed and what pro-Russian telegram channels I was reading). I'm not sure if other devs are still over there. XMPP is so old now - I've used it in the last year but it seemed rough. I have signal but only on my phone where I can't type efficiently.

hodlbod 6mo ago

If there's any activity on telegram, I'm not aware of it. I left the nostr group long ago. I do have a flotilla instance set up just for this purpose, which you can join at relay.nostrtalk.org with the invite code `nostrtalk`. Not much is going on there, the conversation is too fragmented across different sub-protocols, but it's something.

n 6mo ago

I'm looking forward to Mosaic

2bc1cc92... 6mo ago

Have you ever used nostr on a mobile plan? It absolutly *wrecks* your data volume. +1 for binary

Garbage nsec 6mo ago

Spray and pay.

MichaelJ 6mo ago

Take a look at what nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z and nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj have been cooking up lately, if you haven't already. They're thinking about how to move Nostr from a chaotic sandbox into a performant, effective, stable protocol, and they might be interested and driven in exploring some of your proposals further.

Dissident Sound 6mo ago

a wise man has said that humans didn't come to rule the world because we are biggest, fastest, strongest or most intelligent

but because humans are MOST ADAPTABLE

your focus on order, efficiency and reliability will inevitably come at the expense of adaptability

think of it as startup vs legacy business. companies go through this cycle where they eventually ossify, lose ability to innovate and become relics. you seem to want this fate for NOSTR.

on other hand there is a question of whether something can remain a startup forever ? Amazon didn't turn a profit for like a decade. Same for Tesla. it almost seems like the longer a company can remain a startup the bigger it will ultimately get.

some big and old companies like VolksWagen are able to stay innovative by bringing in fresh blood ... for example they recently tapped Nate Rimac to lead Bugatti ... Nate is very young but is doing great work, but i think what is most impressive is that in a company like VW AG that must have had so many seasoned executives VW chose a complete outsider and basically a kid to lead their most prestigious brand ...

the British Royal family also knows he importance of bringing in fresh blood. even though Princess Diana and Meghan Markle both caused major problems for them ultimately they have to take such painful medicine to avoid dying out from inbreeding ...

so in your myopic quest for order and efficiency please keep in mind that this path leads to certain death LOL

you must maintain ADAPTABILITY - you must remain fresh, flexible and open to change

even ancient philosophers ( or was it Machiavelli ? ) wrote that he who wishes to remain consistently successful must change with the times ...

PS: tell nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that he is a fool for muting me. both of you in this thread have come to recognize what i have been saying years ago. you could have all saved yourself a lot of time if you simply worshipped me as G-d.

Noisy signal 6mo ago

Order is what got me in this shit in the first place.

Then blind trust. Compliance. Reliant on government. Believing fake media. Trusting doctors. Expecting the fiat money in the bank, belonged to me.

Trust is the commodity. Not New World Order or in your case Nostr order

Nothing wrong with Black sheep. Expect blowback. I speculate that people on Nostr have received the same reception.

If you believe in yourself and the creative tech services you have offered - its worth celebrating. You don't need approval, consent. Just keep creating stuff that you like. It will resonate.

Nice and Kind Vic 6mo ago

Dev post of the day

nostr:nevent1qqs9kasz8zh5tqdngqn38ag29pm8qdg8qzwd767me4hymm0ezql234gppemhxue69uhkummn9ekx7mp0qgswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgrqsqqqqqpxfm8za

Shawn 6mo ago

"Chaotic liberty is a great space to innovate in. But it is not a good space to build a solid user experience which requires a firm standard and compliance for interoperability. Hence I see hundreds of only somewhat compatible half-ass nostr applications that generally scare users off (which one? why are so many of them broken? and so different?)."

nostr:nevent1qqs9kasz8zh5tqdngqn38ag29pm8qdg8qzwd767me4hymm0ezql234gpp4mhxue69uhkummn9ekx7mqzyrhprfwl7sxpnf247s07g26g7q8xrry3yftz9t3hkmptkeahd38yjqcyqqqqqqgtsrrjj

STERRY 6mo ago

I've always thought calling Nostr a protocol was counterproductive because it's not one thing, it's not even a bunch of things, it's a bunch of types of things which can easily change and break stuff. So it's a big job to keep up.

I don't see you as black sheep but as hardworking sage. I was glad to learn of Mosaic. I've had a lot of the same concerns and ideas for how to improve things.

It takes a bit of courage to suggest a new way but I believe if we're doing it for the right reasons, compassion for users, devs, and in service of nature-like decentralization, and we bring wisdom into our work, we can make a lot of progress!