Hey, GPT, here is your new world and everything you need to know. Congrats on passing the 101 course.
The inscribers will eventually run out of money.. Bitcoin lives on.
It’s also possible you changed your publish to relays, and they are reading from a relay you no longer publish to. So an older version is just hanging around.
It depends a little on how long ago you made a change and how long ago a payment was made.
Your metadata/profile event can existing across different devices and relays in different states or versions.
It’s possible they used a relay with an old version, had your profile cached in their device or simply manually had a copy.
I’ve added metadata_event_id, contact_event_id and relay_event_id to my API for the latest event id known for kinds 0, 3, 10002.
The two problem points I think an indexer should ideally address are:
1. How do I consistently get the latest event id
2. Where can I find that event body (which relay)
I think the problem space is mostly the meta events that can be replaced. And then secondly, in generate, where can I find an event id.
Is this what you were thinking?
I’ve been pondering this too.
How micro you thinking? Basically map event_id to relays that broadcast it (don’t event store the event), or map a pubkey to the latest kind 0/3/10023 events known? Both?
Because Nostr doesn’t have a HEAD concept, certainty around ‘newest’ meta events is hard to make foolproof.
There are a few challenges.
Products will always have a distribution curve for its users. Both on usage and value they perceive or extract. Power users are effectively discounted by regular/infrequent users.
Businesses have recurring costs and cashflow is king. Predictable cashflow is a huge advantage. Subscriptions help map costs back to % sales. Salaries are regular costs.. this is the largest bind.
It can take a while to extract value from a customer or recover sales/marketing expense for that user. A larger upfront fee is a higher barrier to entry and many sales won’t happen. It’s why the refund guaranteed stuff blew up, but died now with subscriptions.
Even when you pause a subscription there is often a business cost involved. Or worst case it’s a liability because you have more to manage that is effectively serviced at your expense.
Consumption based pricing works well for commodities where like for like competition exists and it’s a market driven price. Cheaper can mean same value, just at a better price/discount.
If different options exist, at some point the winning options will take the market.
SSH
WireGuard
Are they examples of what you’re looking for?
Repo with code. https://github.com/blakejakopovic/nostr_xkcd
Basically XKCD has a JSON API. Instead of calling that API, I’ve converted the JSON to Nostr Events. That means we can load the events from Nostr relays instead.
Why does this matter? Well, if we want a decentralised Wikipedia or IMDB, we will need to scale out something similar.
This may explain more. #[3]
Decentralised XKCD now live. Only first 10 Nostr events published.. but have other events ready to broadcast.
Images loaded from XKCD website directly, and I need to use a persistent WS connection - but kept it simple. Example Nostr event below.
I can create a bot that creates a new event per day and broadcasts it. Then it should be current and show the latest daily comic too.
An experiment in building a small Nostr webapp, migrating a simple static API to Nostr, content lifetime on relays, performance (it’s a little slow atm - my fault), etc.
I’ll likely try add image loading fallback to webtorrents. See how robust we can make the app for outages, missing content and no servers.
Decentralised XKCD now live. Only first 10 Nostr events published.. but have other events ready to broadcast.
Images loaded from XKCD website directly, and I need to use a persistent WS connection - but kept it simple. Example Nostr event below.
This repo may also be a good reference. Haven’t used it a whole lot yet. https://github.com/sveltejs/realworld
This is the kind of code that shouldn't have to be written if the protocol (Bluesky, in this case) adhered to the principles described in http://this.how/standards ("Fewer formats is better", one is better than two):
At least they support posts with creation dates before computers even existed.
I’ve just watched a few YouTube videos now focused on v3. The Coracle repo is a svelte app, so worth looking at for structure and ideas - as it’s codebase is pretty large.
I like svelte. Can’t say I’m 100% sold as yet. After I refactor this re-write (close enough to finished today), I guess it will be fair to compare the code.
Cool. I’m re-writing this as a learning project.
Learning Svelte
Hey #[0], was it you that was asking about logging in w/nostr examples? I took some time today to take what I've learned and push an example for nextjs13. https://github.com/jeremyd/example-nostr-login In the nostr tradition, this is far from perfect and just gonna sling it out into the world anyway in the hopes opensource will prevail.
I’ve DM’s you some feedback on the repo.