Nostr Web Client

Some form of "moderation" is absolutely necessary if you want any open space to remain usable by good people.

And shared blocklists are a completely inefficient solution, it belongs more to the domain of "p2p-like ideas that are very cool but do not work at scale".

The only solution I can see is to do it with smart relays that the users choose to act on their behalf, relays with clear policies, reputation and name-recognition, community relays etc -- all interchangeable, of course, and easily swappable on the client side.

Muting people or hiding posts from people outside of your WoT can good solutions to catch anything that slipped through relays, but they cannot work in an actually adversarial environment without destroying the experience in multiple different ways.

nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsqgzj0wmlflrx3x05xdmft5pg0nsshyneuefe24dek2j5udsales6z555pkus

Daniel Wigton 5mo ago 💬 4

I think maybe, we need to revisit "p2p networks are cool but do not work at scale."

The reason for want p2p networks is because they handle moderation naturally.

For instance if I only see what my mutuals post or repost then I am impossible to spam unless one of my friends is an idiot. If that is the case I can easily throttle that friend.

It isn't as good as talking to nobody but it is a heck of a lot better than talking to everybody.

Of course we would like to be able to talk to anybody, but the reality is that guaranteeing universal accessibility is a logical impossibility. For instance if any particle I. The universe wanted to talk to any other particle they couldn't just due to the expansion of the universe.

There is also the problem of the number of possible connections being an exponent. No matter your architecture there is some hard scaling limit.

I propose just accepting that and keeping your local group "small" mutuals of mutuals is very nearly all I care about. Add a layer or two beyond that and you are basically back to everyone on earth.

I think p2p can be done as long as we are honest in what we can expect. Can I set up a node that handles connections from a few hundred mutuals and their average 1 post per day? Yup, not even hard. Scale that out 2 more layers and now I am at about a million or so messages a day.

Limit that to whatever fits in one packet and you are already doing better than twitter for a couple gigabytes per day.

Not great for your phone, but you can keep any message passing to your PC or a raspberry pi that you set up for you and your friends and have the phones download the subset of messages you actually view.

I am not saying it is easy, but I think it is possible to have a fairly good p2p experience as long as a handful of your friends and family are savvy enough to set up a node with a port forward and give you a small store and forward allowance.

Reply to this note

Please Login to reply.

Discussion

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

the main reason why p2p isn't a thing is because of ipv4 and NAT routers

if it weren't for that, it would be simple to just run your own relay and client uses outbox model and caches what it gets from your friends relays in your local relay, which also syncs between your multiple local relays, the one on your phone, the one on your laptop...

that's the hard problem, that the establishment is literally trying to hold at bay forever if they can, because it grants them a monopoly on easy deployment of servers, as they have the resources and time to manage the infrastructure with all the artificial limitations that go with a limited address space.

i mean, 32 bits man. that's literally less than the population of humans, by a factor of two. even if everyone somehow was able to get one for free, half of the population would still not be able to have one.

ipv6 fixes this but we are still at a situation where the minimum allocation of address ranges is 64k. i mean, who apart from corporations needs 64k of addresses? most individuals would be perfectly well served with 256

Daniel Wigton 5mo ago 💬 2

But it can work. You just need some percentage of your local network to have publically addressable IP's port forwarding takes care of that. You can also do ipv6 as well as ipv4. I think most isps support it now.

Again it isn't going to be easy. Not with cgnat etc, but I think it can be done. You just have to have sensible expectations of throughput. The lighter you can make the protocol the better.

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

unfortunately a great number of domestic grade routers don't have properly working automatic port forwarding, and a large number of mobile providers don't give you an IP address, and even more of them don't give you IPv6

i have been saying this for years, the gigacorps don't want us to have p2p because we would discover that we don't need them. it would be one of the biggest industry shakeouts of history. they are shitscared

Daniel Wigton 5mo ago 💬 1

How can they route without an IP address? Are you referring to a cgnat?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago 💬 1

what do you mean how can you route without an IP address? they have one, internally, in the ISP's WLAN, they don't have one that can receive inbound connections.

you don't need an IP address on the internet to make connections out, CONNTRACK on the router handles the internal routing without that.

how it looks is the user has an IP address in common with dozens, maybe hundreds or more other users on the same last mile route. this can be in front of a mobile network as equally as a wired network.

it's getting less common but i'm sure there is still shitty ISPs that don't own enough IP addresses to give all of their customers their own.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago 💬 1

from a technical standpoint, there is several layers to this

ARP is how the routers talk at the base layer

IP is a secondary layer that provides routing capability

having a private IP on a non-routeable address range can still make outbound connections through a router that does have a public routable internet IP address.

how it looks internally, if you can connect a PC directly to the outbound-only capable network is your ETH device shows it has no address, but it has a MAC address which is how ARP from the router's PHY can find the path back to send you the responses to your requests

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

i also should point out that a lot of cheap domestic home wifi routers have "wifi isolation" on by default which means you can't make connections between your devices both connected to the same wifi, without the additional use of a VPN to do rendezvous of your connection for you

fiatjaf 5mo ago

You can do the same in Nostr by just having a relay with whatever restrictions you want.

Simultaneously Nostr also enables global broadcast mode, which is also important to have and cannot be done with pure p2p.

Daniel Wigton 5mo ago 💬 2

True. But you can do it both ways. You can do relays with peer restrictions or p2p with optional relays. (In which case a relay is just a peer with lots of resources. E.g. a static IP and permissive filters.)

You want to have both. I think it makes sense to start with p2p and add relay features, mostly so all the authentication encryption etc just works.

It is a bit more of a pain to add it to an existing open relay protocol without leaking metadata.

Likewise it is a bigger pain to code for the base protocol of a p2p system because all the data you want is encrypted and routing is a pain.

It is just a matter of where you like your pain.

I like nostr because you made the practical choice to make it possible to code for. Very bold of you.

But I also want to see if I can get there from the other direction. It might actually be simpler in the long run. But I admit getting adoption and making it convenient for developers is.... A long shot at best.

Mike Dilger ☑️ 5mo ago 💬 1

What is the difference between p2p and client-server? What people mean by p2p has always been multiple things, and it clouds my thinking when trying to reason about what people are saying.

Every network connection has an initiator. If we call that side the client, then every network connection is client-server... so p2p is not an alternative architecture to client-server, but just some subclass of client-server.

Maybe p2p means that the server is in your house, instead of in a data centre. Or that technically, it is behind NAT and maybe not Internet exposed. In that case holepunching tech might be useful. This comes up a lot. I would drop the term p2p and just say that sometimes relays are behind NAT and maybe we need a holepunching spec.

Maybe p2p means that every server must also be a client, and vice versa, and then you call them "nodes". This seems to be an unnecessary additional constraint on what people can do. I think the server and client components should always be separable. I can't think of a reason to force them together.

This is the extent of my thinking on p2p. If I missed something about what makes p2p distinct, please mention it so I can integrate it into my thinking.

Garbage nsec 5mo ago 💬 2

I think an important part of it is people's expectations. If you present something as being p2p then people are more chill than if you present it as being client server (even if you never use technical terms in your presentation).

The thing is that p2p tech has always been so terrible that even these more chill expectations were far from being met. Playing around with some of this iroh stuff though I'm starting to wonder if the tech hasn't caught up?

https://www.shaga.xyz/ - this is iroh powered and works better than it should for p2p. Something is going on.

Mike Dilger ☑️ 5mo ago 💬 1

Iroh is over QUIC, which has great features but it is UDP, meaning you can't use Tor. So it doesn't provide both privacy and p2p. Also web-based clients probably can't do QUIC and even if they can, they are not going to accept the TLS "raw public key".

No single transport can make everybody happy:

websockets: the only transport that works in browsers. Also works with Tor. But you rely on DNS and CAs and it is the lowest performance choice.

tcp: wouldn't have to rely on DNS and CAs, Tor is supported, and performance is in the middle. But cannot support browser based clients.

quic: wouldn't have to rely on DNS and CAs, and it has the best performance by a long shot. But you can't use Tor or browser-based clients.

Garbage nsec 5mo ago 💬 3

Doesn't WebTransport get you CA-less QUIC in browser? Via the server cert hashes thing? Like as long as it matches one of the hashes *you* provide then you're good?

Mike Dilger ☑️ 5mo ago 💬 3

I didn't know that. I didn't consider WebTransport. I'm reading about it now.

I'm already both excited and bummed. A certificate hash isn't as good as a raw public key. With a raw public key I can a-priori know exactly what to expect before ever connecting. With a certificate hash I need to actually have the server certificate first which has a signature I could not predict a-priori. This can be worked around though. I really hate the baggage of certificates (X.509 is a nightmare of ancient crap). But the industry won't let it go.

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

i think many browsers do support HTTP/3 over QUIC and can do websockets with them, which means that you can support both if you add, probably, some header that requests HTTP/3 if its available if the client supports it and if the relay doesn't understand it, no problem, but if it does, it will upgrade to HTTP/3 web transport over QUICK

Mike Dilger ☑️ 5mo ago

And the damn standard didn't bother to define clientCertificateHashes, only serverCertificateHashes.

Garbage nsec 5mo ago

You could in theory generate a self-signed cert once for a peer/server combo and cross fingers it never changes. Or at least is long-lived. The hash would then come from this cert and be distributed. Then tie the public key to that specific cert structure. Something like that? Dunno. Feels like there's room for jigging. Or use nostr for out-of-band, but that might get circular?

Daniel Wigton 5mo ago

I am doing my own certicates. I am basically doing my own everything. 😛

Mostly because I want to be able to think about how things aught to work rather than how they do. I want my certs to map 1-1 with application scopes. Why? Because I don't want crappy applications anywhere near keys I didn't give them access to. Also you almost never want to use you master Identity key. Every time you unlock it is a chance for compromise. We can't expect grandmother to know good key hygiene

Mike Dilger ☑️ 5mo ago 💬 1

So WebTransport still fails us in a few ways:

* You still lose Tor support. Tor is TCP based.

* You can't connect to a server and verify it by it's public key, you have to have a hash of its certificate somehow

* Client-side certficates still use Web PKI, so can't be used for AUTH

* You layer on a lot of complexity (https://www.w3.org/TR/webtransport/ is not straightforward) with marginal benefits.

I agree with nostr:npub1w4jkwspqn9svwnlrw0nfg0u2yx4cj6yfmp53ya4xp7r24k7gly4qaq30zp about being "connection type agnostic". A message-based protocol can run over any transport, including bluetooth, or paper airplanes.

Garbage nsec 5mo ago

I think it's worth digging a little.

I'm not big on TOR at all, so if that's a game-changer then fair.

Tying a public key to a long-lived hash may be doable, though you'd need a refresh mechanism for when the browser forces. Again though worth digging.

For Web PKI I read chatter before on some kind of push for secondary authentication, who knows, all very new.

Complexity, no doubt.

But I will say that if the performance you get with iroh holds up then it might be worth every trade-off. For me, p2p with this kind of performance is just nuts. Never in my internet history.

Daniel Wigton 5mo ago 💬 1

Not allowing browser based clients is a feature 😈

I kid.. sort of. There isn't any reason browsers can't be extended to support quic etc.

I think you kinda want to be connection type agnostic. There are connections you'd prefer (quic) or connections you'd settle for (tcp, Bluetooth)

The nice thing is that you don't have to develop them all at once. You just pick the easiest to implement and make an algorithm that "chooses" ```return ConnectionType::quic``` then add types after it works at all and as demand develops.

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

i'm not sure there is any practical use for bypassing IP on such things as bluetooth, when most bluetooth devices of any recent vintage are capable of doing it. i mean, it's just a PTP connection like a USB serial bus at the level you usually would use it for this, but PAN is available so why complicate things by using a different flow control protocol (and that's a bit of a nightmare in itself, it's why QUIC still mostly follows what TCP does).

of course, being that it's a point to point connection you can just rely on the hardware based flow control for a duplex connection, or you can implement RTS/CTS in your protocol but ... just why not use TCP/IP when you can

Daniel Wigton 5mo ago

All I mean by peer-to-peer is that there are no special nodes in the graph. I don't really care about the implementation. I only care that things function between 2 isolated users in the same manner that it functions in a fully connected graph.

In some sense that means that every node is a client/server combo but that doesn't mean there are no other connections or that the permissions set on the node can't make it function as a relay, STUN server, or TURN server.

Maybe it is just better to say decentralized but that term might be more overloaded that peer-to-peer.