nostr-next \ stacker news ~nostr

pull down to refresh

nostr-next github.com/mikedilger/nostr-next

280 sats \ 16 comments \ @ek 20 Sep nostr

nostr-next

This repo records various issues with nostr that are unfixable, but that if we started over with a new revision of nostr (nostr 2.0 or nostr-next) we could fix.

view all related items

31 sats \ 9 replies \ @justin_shocknet 20 Sep

Replacing Relay URLs

This is to fundamentally misunderstand why Nostr is.

Things need to work in the browser, and not with some clunky webassembly step in between that won't work everywhere. Nostr over SSL also hides traffic in plain sight in protected networks.

There's been a million attempts at decentralized social using straight p2p comms, and they're useless because they don't deliver to where the user is.

Nostr's pre-history is my work with GUN to bridge Lightning to the web without users needing a web-server, GUN itself only ever had traction because it was a decentralized database for the browser.

We could ditch reliance on DNS

Another demonstrated lack of understanding, Nostr is NOT reliant on DNS, you can use ws directly to an IP (at the risk of breaking the above browser deliver-ability), or Tor if you're peer-to-peer-tarded

0 sats \ 8 replies \ @fourrules 20 Sep

I had no idea that Nostr has a relationship with GUN.eco, how cool!

I really want to break the paradigm of engagement slot machines via event aggregation.

There is a massive opportunity to solve event aggregation now, after so many failed attempts, because LLMs have significantly reduced the cost of parse engineering and web scraping. I'd love to talk to someone who might be interested in helping out the event data on GUN.eco or Nostr.

0 sats \ 7 replies \ @justin_shocknet 20 Sep

by aggregation do you mean backfilling old events?

I actually have a project cooking right now and that's what I'm blocked by, I need to pull 200k attestations at a time and it's going... badly.

0 sats \ 6 replies \ @fourrules 20 Sep

I think maybe we're talking about different types of events.

I mean aggregating real world events, festivals, classes, parties, data locked up in ad funded social media, messaging apps, email newsletters, an assortment of ticketing sites and millions of organiser and venue websites, that forces people to maintain accounts that they don't want, either to promote or to find out what is happening.

Event search is the last great problem of web 2.0, and I think it's the key to normalising Nostr because a tool that aggregates event data reliably with LLMs can host the data on GUN.eco, so anyone can access and build a business off, like Open Street Map for events, solving the cold start problem for many startups.

To access event data and users don't need accounts, so they could easily be using Nostr without having to handle private keys.

10 sats \ 5 replies \ @justin_shocknet 20 Sep

I see, yea I could envision some nostr apps bootstapping themselves with external data... those events would be trusted, but the bot that's publishing them would have its own reputation baked in by the app used to view it.

It's a pretty simple pipeline, but each app you scrape probably needs to have a running service with a custom prompt or logic to do the scraping -> structure the data as an event -> and emit out to a relay(s).

Each app would be different so i'm not sure there would be much benefit to protocolizing it furter, NIP-85 (draft?) attestations might be adequate, they're basically just delegation for a particular stream of data. (these are what i'm currently tying to ingest from a neo4j graph)

(and just to clarify I gave up with GUN because the graph db component was too slow for real-time Lightning invoices, and everything was generally buggy and hard to debug. Fiatjaf authored Nostr after we discussed how I was using it and the struggles.)

0 sats \ 4 replies \ @fourrules 20 Sep

I'm not really that familiar with Nostr, but there are many scraping services, like Firecrawl.dev, Apify, and Matrix can be used to access the data on WhatsApp and Telegram.

I'm imagining an open source tool that curators host, feeding in the sources, adding their API keys for their dependent services, and the licence for the tool would state that they must send the data to some distributed database or else pay a licence fee.

Once available on this distributed DB anyone can use the data. Development is funded by the license fees from organisations who want exclusive control of the data.

I don't know how I'd stop people using the software without sharing the data or paying the license fee, who would also have access to the distributed data aggregated by others.

I assume that with enough eye balls on this distributed data then organisers will publish, either directly or via some automation, to one of the participants that immediately broadcasts the updates.

The important thing is that all data changes are logged in a stream, such as new tickets available, new artist announced, venue change, new event in a series, etc... These would be tagged within a "space", e.g. salsa in London, and spaces would be nested (so all events in salsa in London would also be in salsa in UK and everything in London.

On top of that you could use some variant of the Pagerank algorithm to rank order events by reputation within spaces. Events are effectively valued by the aggregate of the reputations of the participants within that niche, so basically the same as web pages were ranked by Google.

0 sats \ 3 replies \ @justin_shocknet 21 Sep

There's a lot to unpack there, matters of incentives and distribution are probably their own conversation, but I have long considered the concept of "geostaking" in Nostr as an open protocol for stuff in the meatspace. A bunch of scrapers bootstrapping something like that could make it useful from day 1.

0 sats \ 2 replies \ @fourrules 21 Sep

I think it's a gaping wide opening to disrupt the current paradigm because:

demonstrated demand for event aggregation, hence why so many people do it manually within narrow niches
event data is factual, verifiable, with a defined oracle hierarchy (a URL or the person/org who controls it)
in the past the unit economics of scraping event data with traditional parse engineering didn't work
end consumers don't need to create Nostr accounts and mess with private keys to get value from Nostr clients, they can be eased into it, only generating keys when they want to engage with the content)
the data is overwhelmingly public, organisers and promoters want it to be shared to reach new audiences outside their own channels
ad funded social media can't do it because it's contra to the engagement model. If you're enjoying yourself at an event you're not looking at your phone. And event ticketing is a terrible business with low margins so they don't see it as an opportunity. That's why they have tried multiple times and scrapped their attempts in favour of the TikTok model, intentionally breaking real world networks built around the Dunbar number in order to increase the surface area of content a user can engage with.
real world communities are homeless, fragmented into moderated silos to hide bots, spam ,and disruptive voices, which perversely cuts off their own reach, making them more dependent on social media which they often hate
easy to monetise, model it on Substack and Patreon, disrupt the ticketing market by converting regular event goers to monthly subscribers of real world creators in return for perks and access

And so many more reasons.

Due to private key illiteracy Nostr has a massive uphill battle that will take decades, but there is this gaping wide opportunity just sitting there to cut decades down to years, because the one thing that is universal is that people meet at physical locations scheduled in advance, i.e. events.

view all 2 replies

0 sats \ 0 replies \ @melvincarvalho 20 Sep

Would have been better from the start if relays were pubkeys (too)

0 sats \ 0 replies \ @88b0c423eb 20 Sep

I am not technical nor an expert, but I use linux for a long time and also xmpp. Simplex client also seems broken and eat a lot of resources like battery and ram. XMPP is so efficient both on server and client sides.

0 sats \ 3 replies \ @88b0c423eb 20 Sep

We need the help of the nerds from mastodon and the foss world in general. They have a very different ideology from nostr plebs, but we need to find a way to unite the forces.

0 sats \ 2 replies \ @96c0b276a3 20 Sep

Mastodon users dont want to remove tyrants, they want to be the tyrant.

0 sats \ 1 reply \ @88b0c423eb 20 Sep

I agree having ran a mastodon server often there were these woke people ofended by my posts asking my server admin to censor me lol. I get all of that, they are a bunch of flip flop. But there will be some point that they will realize who's the real enemy, the state. And not nostr plebs. That reminds me of people like aantonop defending lgbt stuff, and no surprise he's not on nostr.

0 sats \ 0 replies \ @96c0b276a3 21 Sep

I doubt it. They seem like commies.