2023-12-03 13:33:44
- reply
Member crowdfunding of costs is an interesting approach. The system is not subject to insurance regulation even if it's a company.
Instead of claims being binarily rejected or accepted, everyone gets to vote with their wallet. There's less friction when everyone gets to go by their own decision. Also there's no treasury that can be lost or stolen.
In a bitcoin system, the crowdfunding could be done somewhat anonymously using coinjoins or lightning.
I guess there's tradeoffs as well. More participation is required of members. Getting reimbursed might be less certain, or maybe participants would feel less cohesion when there's no common treasury at stake.
Prediction markets are very interesting for some purposes, but you might not want to reveal your personal insurance claim to the public, or to a random selection of judges like the protocols usually require. Also it may prove challenging to get Nostr folks onto Ethereum smart contracts 😄
https://void.cat/d/LYtnjrkzTbS1JuyjBN29Qt.webp
Japan was amazing. It was great to meet new and old nostrich friends and get to know some of the Japanese community. Enjoyed the Tokyo vibe and t-shirt weather in November. Japanese food is in its own league.
Unfortunately I got pneumonia from the trip and spent 2 nights in the hospital back in Finland, getting IV antibiotics. It was an interesting experience, makes you appreciate health.
I'm mostly back in business by now, although haven't felt like going to the climbing gym yet.
Currently working on a 3-column layout for Iris & Snort. Iris is like a beta version of Snort: I usually deploy every commit, so it's already there 🐒
Looking forward to the next gathering of nostriches, and working to get some cool stuff done before it!
https://cdn.nostr.build/i/387f804f0cee356c528dff8fc31c238dd9c4ff6c7261385b0fc879496d3ea076.jpg
Spam prevention should work by discarding events from users that are not connected to your social network like normal users are. For example, swarms of users that are connected by only 1 or less follows from legit users.
Iris already discards messages from completely unconnected users, but need to add shared block list support and better detection of sybil swarms.
This should work especially for trending algorithms, where reactions from socially connected users are more valuable anyway, and missing a like doesn't matter so much.
Currently Iris trending list comes from nostr.band, but I want to do it locally at some point. That's the only way you know what you get.
https://cdn.nostr.build/i/6edff5425a08b80a279726e215e92c812ba3155e0b70f157673d92e8cb0fc851.jpg
While relays and file upload services are a simple and effective way to get started, I think p2p is the future.
Running a relay or file uploader is expensive, and you need content moderation. On the other hand, p2p is "free" because people are already paying for their own internet access and on-device storage, or even cloud storage. P2p is also much more censorship resistant.
Video hosting is so expensive that I imagine it will be the first thing to be moved onto bittorrent. If you don't like torrenting with random people, you could connect to people in your Nostr social network.
When Nostr becomes popular and free relays dwindle, maybe p2p becomes more common for event sync as well. Direct connections are also better for DM privacy.
If bittorrent is too clunky for general-purpose file sharing, we can devise our own file sharing on Nostr. Nostr is already based on content-addressed events. Just need a binary format and some standard for file chunking.
Iris now supports secret chats that don't leak metadata, implementing the https://hrfbounties.org/ bounty #3. It works also for group messaging.
It's a quick & dirty solution, but works. A shared nostr account is created for the secret chat / group. Its nsec can be shared via link, qr code or invite message from a single-use anonymous account.
Users can then communicate using the shared account's messages-to-self. Iris signs the inner messages with your own key, but the arrangement could be used for anonymous group messaging as well.
I'll also add inner message encryption at some point, so you can ensure that only certain group participants can read the message.
This arrangement doesn't introduce any new event kinds and works also in clients that haven't implemented a special UX for it. You can just log in with the nsec and message yourself.
I had to disable the Iris social graph filter to let invites through, so now Iris DMs are open to spam again, but I'll try to figure out a better solution.
As always, the UX needs a lot of attention, but I believe here's an MVP.
Screenshots:
Alice wants to message Bob:
https://cdn.nostr.build/i/e3921dfe10d63d6765aa98f6ed19903a590d91d59e842284f3c8bb379cdb1bee.jpg
Alice sends a secret chat invite to Bob:
https://cdn.nostr.build/i/ce35ff1a8db2e1f318319062e9d7c95fa48784b80d473bba20fb1d081207accb.jpg
Bob automatically follows the invite from Alice. They can now message each other in the secret chat:
https://cdn.nostr.build/i/2f4af356351b2dfbe26c30a9614627af242e993ecff7b774c485fade214f2bba.jpg
Here's how the invite looks in another client. I will add an "nostr:ninvite" URI in addition to the nsec.
https://cdn.nostr.build/i/0f7516439b598f8d8012dec6db74bc7e39252bb5b8fc36873200a1eafed8bf8a.jpg
2023-07-29 16:00:59
- reply
I want to add new stuff like group names and pics, maybe share webrtc metadata, and I don't want to have to specify a new event kind for it.
When you want to do something new, would be easier if you could just do nostr.set('group/[id]/name', name) for example. If you want to build something complex like a mmorpg on nostr, that becomes even more critical.
You could discover all data on nostr by just browsing the file tree, with human readable directory names and nested structure instead of arcane event kinds.
You could update a single value on a list without sending out the whole list and risk overwriting another version that wasn't synced.
You could even easily unlike notes (nostr.set('likes/noteId', false)), and wouldn't need to separately implement delete event handling. That's how Iris used to work on gundb.
Actually tag-replaceable events already enable saving data to a "path", but not directory listing. While relays don't support dir listing yet, I can build a client side API prototype that subscribes to all tag-replaceable events by the user.
When you want to do an aggregate directory that shows writes by all your follows for example, relay side dir listing support becomes more important.
There's so much work to be done with even the basic social networking stuff, but I'll try to get a simple file explorer proto done at some point.
