time to upgrade macos ...

good thinking. i'm on macos, so would need a simple way to route the system audio as a recording input. unfortunately, to the best of my knowledge, macos doesn't make that simple...

what's the easiest way to clip a few minutes of a longer YouTube video, and save it as an mp4/mov ?

#asknostr

this is why LN scales txn throughput, but not self-custodial userbase, sadly..

my clients struggling to '@'mention you, so I'm just going to drop this here

https://www.youtube.com/watch?v=YIwPKoYG-2Y

looking forward to this 👍

sorry I missed you folks. I will make a note for next week 👍

I'm not sure how it works in terms of the current implementation, but one of the consequences of building a self-hostable solution based on WebRTC would be that each chat participant would need to maintain a direct connection to all other peers in a chat channel. (Keeping the connectivity peer to peer would help to keep the overall latency low, and allow the primary 'signalling' server to be spun up on very lightweight hardware, ie raspberry pi's, mobile clients, etc.)

To facilitate this, chat participants must be willing to expose their IP address.

Do you think this is acceptable, in terms of the privacy aspect?

The same is true from the perspective of a user who is running a 'signalling server' / self-hosted instance. They must be willing to expose their IP/hostname, and ensure the necessary paths and ports are open, to allow requests into their particular network.

It makes me think about your approach to Zeus/LNBits, in terms of reverse proxying via CloudFlare...

I'm wondering if there is a means to implement something similar, but without necessarily relying on an external third party...

I'm reminded of vhosts, on IRC, back in the day, but I'm not sure it would be possible to use this type of scheme to mask ip/hostnames, without needing to also proxy the data/traffic through the central signalling server, as opposed to keeping connections direct, from one peer to another.

Can we get some more thoughts / opinions ?

I see that Jam also offer an SDK, as a basic third party library... https://gitlab.com/jam-systems/jam/-/tree/master/ui/packages/jam-core

Something like that may save a lot of heavy lifting, and could significantly reduce the overall development time, in terms of of a re-write, but I take the point that you're inviting in a variable degree of uncertainty & bloat, by leaning on a third party.

It would be very interesting to get input from others on what they perceive as the best path forward, in terms of the technicals.

I wonder if a lightweight WebRTC implemention might be a reasonable starting point? Or am I overlooking newer/more relevant browser based comms libraries/APIs?

Hi nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424. In your view is the Jam Systems platform still the most viable starting point for a Nostr Nests re-write? Or are there other open source / web based audio conferencing platforms that are worthy of consideration?

sounds good to me. do you meet at a regular day / time ?

chick at 1:20... that's me right now

what's the reccommended amount of time to spend in there?

There are cypherpunks, there are NGU maxis, and there are those who simply observe reality without opining...

Two things can be true at once, ie the importance of self custody, and the economic reality of non-custodial solutions...

For many parts of the world, 'Thanks Giving' isn't even on the calendar...

WoS are not US based, therefore it's somewhat unreasonable to expect them to be mindful of US public holidays...

Lightning helps scale ecash by giving mints a low fee way to interoperate. This is what allows users of different mints to transact with oneanother, without having to join each others mint.

fascinating. going to need to research further.

I listened to your podcast with Peter McCormack. Any chance you have any others? perhaps a little more on the technical side?

it's already happening with projects like Fedi.

does it connect directly to other LN peers? keep some sort of copy of the network graph, etc?

there's a good argument that having the optionality of hundreds of PayPals , vs a single PayPal, would force the original PayPal to think longer and harder before engaging in censorship, etc.

agreed, custodial solutions are not the goal, but if they help democratise the existing landscape, i'm not sure any of us are justified in dismissing that...