Heya!

🤤

No trading knowledge needed. Zaps are just a way to use the lightning network which uses Bitcoin, to show appreciation to someone else with a small amount of Bitcoin. Otherwise, that’s all you need to know really.

You may benefit from adding a few different Nostr relays. In Damus, you can find someone you like, tap their avatar and see their list of relays. Maybe try adding a few like that.

🏆

Followed. nostr:note1f7ewcq5m9dxsfsftf4se2uuv7c82lt6whewfwxsgfp0rwjchskwsnxhtp0

I’ve heard it’s great to sell their jewellery, and give them the #Bitcoin proceeds to get them started. Apparently it works every time.

Nostr is rigged. nostr:note1nkum3r9scny6lssvr5cqlggw4k9t5r874lysqhgkeznx7v0wqzjqy4cypd

I’m a few days you’ll be a pro. Zapped you a few sats!

My first chat bots. ChatGPT is just a clone.

Welcome #[2]! nostr:note1h3lewhk2az7sve83ejutncxtddu3qdlaw66h3x0va3zwuvcvgjcqdys6gw

I’m pretty sure we can create shareable Nostr service definitions something like this - as Nostr events. Some parts definitely need decisions made to make them flexible. And perhaps even input validation rules.

# Nostr Service Definition Specs

provider_name

provider_website

Paid?

file-upload

* Service type: file-upload

* Service name: "cdn.wako.ws file uploads"

* Auth methods: NOSTR-NIP-98

* endpoint, POST, JSON = https://cdn.wako.ws/upload

* Inputs

* file (multi-part)

* Accepted file (content-)types - [MIME] = image/jpeg,image/png

* Multiple files accepted: bool = true

* max request body size bytes =

* Response

* Success = parsing/field/key (json.dot.walk filter) = .file_url

* Error = .message

translation

* Auth method: API_KEY

* endpoint, POST, JSON = https://translate.nokyctranslate.com/translate

* Inputs

* q (text)

* source (ISO 639-1)

* target (ISO 639-1)

* api_key (text, .api_key)

* max request body size bytes

* Response

* Success = parsing/field/key = .translatedText | .translations[0].text (.join(" ")

* Error = .message

This was my experience too. I don’t know if recognised a single name from your recommendations. Band felt more like k-means clustering on follow relationships.

GN!

🫣

My use case is more focused on content creators who want some control over their content distribution and logic/rules. Maybe it’s as simple as members get to see content 2 weeks before everyone else.

If it’s general public content, and no payment or access checks are required, for sure - hash content addressable over http/p2p/Nostr relays is fine. I like it.

#[3]​ what’s the Nostr.wine paid user event retention policy?

Snort premium seems to have event retention as well. “Unlimited note retention on Snort relay”

https://snort.social/subscribe

Thanks. Makes sense.

Only partial issue is unless the CDN also has an auth layer, you’re redirecting to a ‘anyone can read’ link. If member access is required, this doesn’t work sadly. Unless you know of a one time key approach.

Fair points.

I think most content creators tend to be self learners and willing to follow a guide or setup, if they find the outcome valuable.

The every day common consumer - far less likely, unless it’s a tap to configure.

I’ve already built a functional POC - but would need a lot of work to consolidate before open sourcing. Making it as simple as possible.

I’d also love perhaps to have services that providers can advertise via Nostr events. There can be a spec file, and then upload providers can publish their spec and service offering. Apps just use that config to add them as an option.

I think it’s small in the sense that currently people are using centralised hosts like youtube, Patreon and OF. If you want personalisation (email, NIP-05, website, etc) and de-platform resistance - you’ll need to at least control the domain.

And if you add in subscription services where to access content you need to use Nostr HTTP AUTH - then that can just sit in front of the CDN data.