Avatar
Rod
1bda7e1f7396bda2d1ef99033da8fd2dc362810790df9be62f591038bb97c4d9
Startup founder and listco CEO, New Zealander (kiwi) expat living in Australia, #nostr #austrich, dad. - Nostr Blog https://rodbishop.npub.pro/ - Nostr FOSS https://github.com/r0d8lsh0p/ - Nostr Live Streaming nostr:npub1sh0spghk4yvy2d2v35kelw45qq4msk6zykaw4ds047e9slzs8r4qr7q2xa - Nostr AI nostr:npub1ahjpx53ewavp23g5zj9jgyfrpr8djmgjzg5mpe4xd0z69dqvq0kq2lf353 - Jayride (ASX:JAY) - Fishburners - #Bitcoin miner

There's actually quite a lot of live content on Nostr already and it's only just getting started.

I built Sho Bot as a way to test the Shosho push notifications server before turning it on for everyone. It simply posts a kind 1 when a qualified Nostr stream goes live.

But now reading the feed there are streamers here that I never knew existed. As a user I'll be getting 2+ relevant pushes from my follow list every day, which is plenty.

Way to go everyone. Keep it up!

nostr:nevent1qqsfrhxnaa4q8uqxng034e08k3ee774d3plnj7h6r43792mnjpsd4hcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyzza7q9z7653s3f4fjxjm8a6ksqzhwzmggjm464kp7hmykru2quw5qcyqqqqqqg37kj9n

I think we fixed that annoying padding that appeared in your video between the keyboard and the chat field.

Anything else needed to tighten this integration?

Once you mentioned that you use Nostrudel event creator tool to create your own 30311 live events.

I am thinking of making a tool for simply that, with a nice web UI where you enter your HLS URL and just press "publish"

A way for non-Nostr streamers, especially those with multi casting setups to quickly "announce on Nostr" the streams they are running anyway.

I'm interested in your advice -

Does that sound like a useful thing?

How/for what reasons do you currently manually publish your own 30311s?

Maybe not exactly this one, but yes that's why I was playing

It's about time Australia got with the program. Are we really going to defend our wildly unpopular censorship commissar at the risk of our relationship with the US?

Playing with character design. Midjourney animation is really great

I wonder if it is bad etiquette for my server to maintain multiple 24/7 subscriptions to multiple popular relays ... Or, no worries?

Here is what I think I'm building.

Server maintains 24/7 persistent websocket connections to a set of relays with two subscriptions

1. For all kind 30311

2. For kind 3 where author is one of a set of n'000 pubkeys that have requested push.

Each time a 30311 comes in, compare the 30311 host to the kind 3 lists, and if the host is present in a user's list, push the user.

But I wonder

Isn't that quite spammy and taxing to maintain 2* 24/7 subs to each of a set of public relays?

Or is it no drama at all?

Replying to Avatar Sebastix

For sending push messages, I used https://github.com/web-push-libs/web-push-php in https://www.drupal.org/project/pf_notifications

So no platform solution there, but sending the data directly to the endpoints of the vendors (Apple, Google, Firefox etc).

Thanks Sebastix! For clarity I have the push side of the equation worked out using Expo Notifications. What I don't quite understand is the best pattern for my server to become aware of the Nostr events that are the trigger for the push.

Hi friendly Nostr devs.

What's the best pattern for push?

I have a server with a db of npubs and push tokens from my app.

If an npub follows another user, and that user goes live, I would push to the npub's token "user is live! heres a link"

Should my server maintain a persistent connection to multiple relays subscribed to all kind 30311s to identify when all lives start?

And, similarly for follow lists, should I persistently subcribe to all kind 3s? (And then wash them against npubs in my db, or perhaps specify 1000 author pubkeys in a req?)

Or some other pattern? It's all seeming quite inefficient and spammy on public relays...

Maybe I am missing an obvious layup e.g. somehow populate my own local relay with all kinds 3 and 30311's and connect locally with impunity?

What pattern have others used? Are there docs on this? #asknostr nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9u2mk7fe nostr:nprofile1qqsqvcu68pkfcyq5y9mz9n9u7sys33835rpnuglc6mtg7j4lv40c7ugpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszrnhwden5te0dehhxtnvdakz7k6tgvl πŸ™πŸ™

Yet to try, just researching it now.

Seems superior to my current setup of VSCode and Cline in that it is designed for multi-agent asynchronous work, and has a specific opinionated approach to tool approval and completion review steps that makes a lot of sense.

Rather, Shosho provides the camera, instead of zoom. Maybe I do not understand why zoom is required.

Well I agree to focus on Nostr's points of leverage, and not needing to name Nostr at the time you try to cross the chasm. But, I don't see any reason to pull punches, so if you're not pointing yourself at a $bn+ competitor incumbent then I would say you're aiming small. The benefit of aiming big instead is you're not taking any business model risk, you get to simply copy and incumbent and be a fast follower riding better rails.

Its the early hours of the morning here so, quick thought and can flesh out later.

1. I was vibing a docusign using nsec signing. Few lazy afternoon sessions and good progress. Docusign market cap $16.5B. I don't need or want to do another startup, let alone a replacement strategy play but a small team could displace chunks of the b2b stack with new economics. Pipedrive disrupted Salesforce. Can a nostr CRM disrupt Pipedrive because trojaning npubs into business is πŸ”₯. But don't talk about nostr, talk about solutions.

2. nostr:nprofile1qqsphkn7raeed0dz68hejqea4r7jmsmzsyrephumuch4jypchwtufkgpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgewaehxw309aex2mrp0yh8ymmyvf5hx6r0wqhxu7303hr2v8 may want to share what he is doing. Another sector with significant incumbent revenues and less friction.

3. The point being, products (not hobbies) first. Monetization is a deliberate act. Jack can code bitchat without concern for monetisation. But that is a byproduct of silicon valley success and mindset. I've built startups outside SV and you have to be pragmatic about monetization.

4. There was an excellent 30023 about a year ago by somebody who tried to build an app using relays as a data store and how slavish commitment to a protocol may be the wrong formfactor for the solution. Maybe some apps just stand on the shoulders of the protocol but aren't prisoners to its original libertarian ideology. It's a protocol so you need zero permission to use it in the way it serves your customers.

5. Shiny objects. Vibing clutters the landscape with broken projects. We need a badge for apps that have a product person and a malevolent tyrannical committed QA function that demands the product serves customers, not the autist hobbyist creator (I'm talking about me of course)

Back to bed.

Two $bn businesses here.

1. Video streaming sales. Whatnot ($5bn GMV), Tiktok Shop ($50bn GMV). Fast growth commission on sale model. But what is it? Live stream discovery and chat (NIP-53) and ecommerce (NIP-99). Build on Nostr rails solves chicken-and-egg, reduces time to market, and then pitch it to Whatnot users who can just use it, without knowing how Nostr works. I am building this with nostr:nprofile1qqsgthcq5tm2jxz9x4xg6tvlh26qq2actdpztwh2kc86lvjc03gr36spzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtckgrenr

2. ERP with workplace chat. Slack (aq by Salesforce for $27bn). SaaS MRR model. But what is it? A workplace identity (NIP-01) and SSO (NIP-42&98) system with chat and where data can move between silos (on Nostr!). Compete with other ERP and workforce systems on two key principles 1) interoperable with vast open source ecosystem for free. 2) no platform lock in ever, take all your data and leave whenever you want.

There are more. These bones are great. Just need businesses on them.

nostr:nprofile1qqsda2memtapc2lykjnd8t9px4ake2stw39lg6k49xj6u3jz3pteu6qpz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309amk7apwv3hhwmnfwdhkuargv46hqtnrvyhszythwden5te0dehhxarj9ekxzmny9u6elzz9 πŸ€―σ „΄σ …™σ …”σ „σ „Ήσ „σ …šσ …₯σ …£σ …€σ „σ …£σ …•σ …•σ „σ …©σ …Ÿσ …₯σ „σ …”σ …Ÿσ „σ …‘σ „σ …£σ …•σ …“σ …’σ …•σ …€σ „σ …“σ …Ÿσ …žσ …€σ …•σ …žσ …€σ „σ …•σ …σ …Ÿσ …šσ …™σ „σ …‘σ …£σ „σ …‘σ „σ …›σ …™σ …žσ …”σ „σ „§σ „σ …žσ …Ÿσ …€σ …•σ „―σ „σ „Έσ …Ÿσ …§σ „―

Replying to Avatar Laan Tungir

Yeah, I have slowly been putting my ideas down about this. I guess I have time to ramble...

Calle and Laan are software. We code, and we are code.

While we are software and abstract, for us to run ourselves and our code we need computers, and computers are physical things. We are bits; our computers are atoms. Unfortunately, our computers, bodies, and communication networks are made of atoms, and they are subject to physical attack.

I believe as a cypherpunk, our main concern is defending against physical attack. We tend to think we exist and work in cyberspace, but we really have to concern ourselves with meat-space.

We have a couple of tricks up our sleeves. One is obviously cryptography, and I think 90% of the heavy lifting of NOSTR and Bitcoin is getting everyone to physically secure a private key. An emphasis on PHYSICAL. Securing a private key is a physical process, not a software process. It is instantiating the key into atoms, defending those atoms, and keeping them private.

NOSTR is good here because as a protocol it remains loose enough to innovate on. Once everyone has a private key, you can go a long way without having to define the networking. Relays, snail-mail or carrier pigeon: you know that this event is from me to you, because we use keys.

I think that the cryptography part is pretty well understood, but we have another trick up our sleeves: the commodification of hardware, or maybe even better: the "roachification" of hardware.

It happens to turn out that in our universe, once a computer can do some very basic functions, it becomes "Turing Complete" meaning the computer can run ANY software in our universe. Some Turing computers have more memory and some are faster, but they can all run any software program to some arbitrary number of steps.

If/when the aliens land, they will be able to run Microsoft Windows on their computers (god help them), and we will be able to run their software. It's an amazing fact about the universe we live in.

This means that you, I, and our code are SUBSTRATE INDEPENDENT. It doesn't matter what the computer is made of: silicon, carbon, DNAβ€”it's all the same. It doesn't matter where the computer is. As long as it can compute.

So while we live on/in computers, and depend on them, they are interchangeable, and fundamentally a commodity on a physics level. Our code is special; our computers are a commodity.

If we recognize this underlying fact about our universe, we can utilize it in our code to give us a great advantage.

Bitcoin's strength is not that it defends its computers; it's that it treats those computers (the nodes, the mining ASICs) as the commodities that they are: redundant and expendable. There is no special computer in Bitcoin.

In my estimation, NOSTR comes the closest of the communication protocols in understanding this. A core tenet of NOSTR is that relays are dumb. Expendable. Commodities. We want the world to be awash with them such that they are like roaches. You stomp on one, and two more appear. They need to be easy and cheap to run.

So I would say that the two key ingredients of NOSTR are:

1. Keys

2. Commodification of hardware.

There are things about NOSTR that I think could "use improvement," but I love it.

Once I discovered NOSTR and saw that I could take my overly important home computer, separate the software from the hardware, turn the hardware into a commodity, and spread my software globally across the internet such that it is everywhere and nowhere, I was hooked.

One of my goals is to be able to walk up to any standard computer, enter my key, and have the entire world that I built in cyberspace available to me. My code, my communications, all there.

My money is controlled by me. It is everywhere, and nowhere.

My code and my network can now be controlled by me. It will be everywhere and nowhere.

Now if I could only upload all of myself from my brain, and save it from this slowly dying computer I am running on.... that would be something. It's actually a good thought experiment, and way to critique a protocol. Imagine you upload your brain to the internet, and you don't want to die. How would you design the network that you live on? The physical infrastructure as well as the protocol?

We should think about this question because it is ultimately what we are doing.

Oh wow. Yes

Hi nostr:nprofile1qqsx8lnrrrw9skpulctgzruxm5y7rzlaw64tcf9qpqww9pt0xvzsfmgprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshssfnq7m if shosho users want to delete their stream event from the network (as with an old or test screen) can I do this via the ZS API at all?

I do not see mention of delete in the docs.

Thanks Kieran

New test result

1. Top up balance now works, thanks

2. Stream with zero balance to free tier still fails. It connects and immediately disconnects vs expected that free tier should work with zero balance -

Can you please reenable streaming to free tier with zero balance?

3. First stream connection always fails regardless of tier or balance. Very disconcerting for users -

Is there a pattern you recommend following e.g. build in instant auto retry?

In your screenshot your RTMP server url is empty. You would need to try again using the credentials I gave you. It needs to look like this.

Replying to Avatar _

The url should end in m3u8 like

Hi both

I have created some credentials for you to use temporarily at my cost. At some point should cost run up, I will delete these, but in the meantime just use them however you like.

Stream key: "f74f751e-33c0-472a-a176-47cdb26d50ee"

Server URL: "rtmp://broadcast.api.video:1935/s"

Playback URL: "https://live.api.video/li3p7jKilEfIAMcCJfa5NTDz.m3u8"

To add these to your app, press on the server, then press "add" - see the readme on the GitHub at https://github.com/r0d8lsh0p/shosho-releases

Anywhere Nostr streams are shown – Shosho, Primal, Amethyst, Zap Stream, etc.

Hi both

I have created some credentials for you to use temporarily at my cost. At some point should cost run up, I will delete these, but in the meantime just use them however you like.

Stream key: f74f751e-33c0-472a-a176-47cdb26d50ee

Server URL: rtmp://broadcast.api.video:1935/s

Playback URL: https://live.api.video/li3p7jKilEfIAMcCJfa5NTDz.m3u8

To add these to your app, press on the server, then press "add" - see the readme on the GitHub at https://github.com/r0d8lsh0p/shosho-releases

From the screenshot it looks like the app is failing to connect to the Zap Stream API. Zap Stream has been having troubles over the last few weeks, on and off intermittently which may cause the issue.

If ZS isn't working then you can alternatively use any other RTMP server. If you like to set one up easily, you can use API.video to get one, then press on the server in shosho to add the new server details to the app.

I will also take a look next time I am back at the keyboard.