Migrate to svelte 5 xd

Btw I looked into it, hard to find sceptics of runes. Did you run into issues with serialization of proxies or were there 3rd party lib api compatibility problems?

What important use case did cause you dislike it?

Yeah we could explore this idea to connect onboarding with job sharing somehow. Interesting.

Excited about this for SatShoot!

Will look into how Vertex could broaden the field of view of clients and freelancers if they opt into it.

Nostr is no exception: If you can't program it, you don't understand it.

#daviddeutsch

If you have some important feature you would be willing to pay for, a friendly reminder that SatShoot is specifically for those use-cases. It will get a major facelift this month.

Gotta shill my project when I see a good fit. :)

Hope your project advances, grateful for your work!

Yeah now that you mention I read this a while back.

I also commented on it but somehow left it in draft.

...Reading through these and the issues associated with it is very useful but still leaves some confusion in my mind.

Managed/unmanaged groups, nested groups, combination of these, rooms, relay support, relay implementation dependency, feature detection...this is the most confusing spec in that I really find it hard to identify the use-case I want to go with.

But this won't stop me from taking steps toward my plan. I think I know now which way to go.

Can you write a longform on this nip29 saga some day, so we can learn from it? I enjoy your articles on nostr development

I thought your spec was being made compatible but not identical

nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzpmhxue69uhkummnw3ezuamfdejszxrhwvaz7tmddahxzepwdf3r2dfwvdhk6w3cxqurqqgdwaehxw309ahx7uewd3hkc0v9nh0 I was wondering is #notedeck going to be able to support a relay-centric moderated community column? I am thinking of a column scoped to a specific relay with auth and supporting either hodlbod's [NIP](https://github.com/coracle-social/nips/blob/relay-chat/xx.md) or NIP29.

I see issue #376 that single-relay column is planned ideed but what about functionality related to semi-closed groups? Is this perhaps possible with #nostrscript -enabled columns?

Context:

I am exploring possible options to create a discord-like space on nostr where I can hang out with Freedom Tech builders.

So far #flotilla seems to be my best bet from nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7208x3z but it is not optimized for easy and performant widgets that I need to have the best possible nostr experience tweaked to perfection for me and members. I would just share the required columns for the group and they could add it to their nostr experience.

The discussion in my relay would be moderated but it can exist alongside whatever ppl prefer to add for themselves.

Tradeoffs right? XD

My Solution: SatShoot.

I got interested in this back when I wanted a P2P market for bitcoin self-custody troubleshooting.

Expanded the idea to general freelancing that became [SatShoot](https://satshoot.com) .

My approach was to introduce a whole new kind(nip description [here](https://github.com/Pleb5/satshoot/blob/main/apps/satshoot/EVENT_STRUCTURE.md) ) for the gig economy because it can capture the use-cases better with specialized tags for title and status of the job(description is the content field), and include any tags related to the topic of the gig with "t" tags.

The best part is that with the new kinds a host of freelance apps can evolve instead of centralizing around kind1 apps, having already very bloated UX problems.

Also, to have the opportunity to assess multiple bids on the gig properly and select the best one, I have a simple "Offer" kind which has amount, payment method and pitch info associated with it. The client takes an Offer which is recorded in the Job kind. This can be thought of as a contract of sorts.

To enhance decentralized discovery of reputable counterparties, I included the option to review each other as client/freelancer, as well as public zaps and nutzaps (built-in Cashu wallet) as payments. Client-side web of trust and outbox model further help with disintermediation.

..Nonetheless I included a feature to extend reach and post Job as a kind1 note for now.

The app, though functional now (and had gigs posted and paid in multiple cases), has been under heavy UI/UX-related development for the past c.a. 2 months, which I hope to share this month.

What a bummer.

Wonder how they justify this decision, will do my due research.

Thanks for this explanation!

I had svelte 5 on my roadmap. Now I'm unsure... it was supposed to simplify reactivity.

I just love your ideas! Keep them coming!

I would start by taking a project I like and setup a basic devshell for it, using some LLM and the nixos learn section as a guidance and as a learning tool to explain steps and dive deeper in certain topics.

E.g. nix-bitcoin is a highly configurable nix project that you can use to define and run an onchain/LN node, joinmarket and other bitcoin related software.

Nixvim is another one if you like neovim.

Or just grab a project that has a devshell already defined and try to make it work.

[Notedeck](https://github.com/damus-io/notedeck) is an example that is nostr-related and has a nix shell defined that you can play with.

Shopstr.store

It is my daily driver.

Steep learning curve (depending on what you want to use it for) but for devs it is worth the time investment imo.

My favorite feature is the isolated dev shells. And nixvim.

Ppl have used http to fetch nostr events and I think there are some who still do.

Fiatjaf doesn't like it I know and this has been heavily debated back in the nostr telegram group days.

My guess is this: most apps most will end up keeping a connection alive to fetch multiple things from a relay as user navigates the app and even post things, with relatively high frequency.

Relays want to aim for simplicity mostly so they expose websocket connections to handle the common use-cases instead of having REST too. I think the EOSE is kind of the equivalent to an http response so that you can close the connection if you don't need anything else. Most libs/sdk-s have "closeOnEOSE" option therefore.

You are right assuming it is not very efficient to try to find _all_ profiles matching one name(e.g. odell). In the metadata case you cannot use a tag in your filter which leaves you the only option to use kind 0 and that is a lot of events even from one relay to sift through.

On the other hand, tag filters are restricted to one letter (e.g. "#e") type of queries for obvious indexing performance reasons. There is no "#n" tag to query for because it doesn't have a special treatment in profile metadata fields, I don't know the reason why(maybe it's there in some nips discussions).

What most devs do is that they have a logged-in current user in their app usually which means they can by default grab a follow list of this user and perhaps also extend that with some web of trust algo into an extended network of trusted pubkeys. This could be on the order of 10 thousands of pubkeys. If you only grab metadata for these (and maybe defer some fetching into the future to gradually download these after login with time and also use some caching) and that will be most likely a feasible task to do.

Not everyone uses web of trust so you can even just rely on direct follows, its up to you.

So it is important in nostr to do smart queries related to the context your user needs or might soon need, because you can be drowning in events or get substantial lags and disconnection issues pretty soon if you make wrong/unreasonable decisions.

The takeaway is, there is no global on nostr so you need to adjust your app design and expectations to reflect this reality.

Filter:

Nip01 describes how to construct such a filter with kind 0, since and until fields. After that you just match content of downloaded events.

A different approach is to search for human readable strings on relays which support [nip50](https://nostr-nips.com/nip-50) but that is not yet widely adopted afaik. You could try nostr.band relay e.g. See nostr.watch for nip support and other metrics of different relays.

Relays:

You can't strictly get _any and all_ notes in nostr because you would have to go to and access each and every relay there is, which is unfeasible. You have to select some reasonable relays to your use cases.

In your case I would hit some well-known metadata relays like purplepag.es .

Fields:

As to the name and display_name, there are different nostr apps using different conventions for this. Best-off you check both. Also you can check well-known sdk-s like [NDK](https://github.com/nostr-dev-kit/ndk) or [rust-nostr](https://rust-nostr.org/) how they go about this and other fields/tags of nips.

Feel for you.

Too many landmines for freedom tech in iOS. Not interested in that.

Totally captured unfortunately.

#support

Hey there, I am new to relay-tools can you please enlighten me:

1. There is no "async" join at the moment - ie I see no option for people to request joining and then I would be reviewing join requests. For people I havent whitelisted therefore joining is automatically refused. I wonder if this feature belongs in clients like flotilla or relay-tools

2. Can a relay be renamed?

3. Can I delete posts from my relay ? I only saw moderation as black/whitelists but I would like to have fine-grained control and be able to delete after the fact

Thanks for this service!

Test zap goals

It is working quite well for most intents and purposes. Some issues we encountered:

- Issue statuses editable by anyone

- Text of issues not editable after posted

- Cannot assign npub to issue

- Cannot link issues in description

- No labels for issues yet

- Multiple ssh git identities caused some tricky situations

So although there are rough edges, we could work our way around most of these things.

It is very actively developed by an enthusiastic group of contributors so I expect rapid improvement

Lex Friedman:

"GitHub is... basically a place where developers go to be happy. And to collaborate and to share and to build. Especially for people who are part of the open-source world."

I think they go there because they have to. Another centralized silo but this time it's more pernicious and problematic than the usual social media platforms.

It's not about code. Git servers are all over the place. It's about the social coordination around that code. Social interactions are vital to keep a project going. And it is all captured in GitHub which can rugpull you anytime.

PR-s, issues, comments and discussion threads.

All belongs to Microsoft who owns GitHub. And we have been feeding this beast for ages now.

Do you know what else belongs to Microsoft? LinkedIn. It is a platform most likely substantially bigger than X (actually it was taken private years ago) and it controls how most work.

If you haven't been checking what is going on in LinkedIn nowadays (good for you I guess) just out of curiousity, please do. You will be shocked.

I believe nostr can break this diabolic situation. We can make these platforms obsolete. At least for the freedom-minded. That's what I'm aiming for.

Today marks a win for privacy!

I was planning to get NIP17 DM-s implemented in #SatShoot but figured this functionality actually belonged in #ndk, so others could benefit too.

Then I saw that some work had already been done on this front but never finished completely. Since I couldn't make time for it at that time, thought I could post a Job on SatShoot and perhaps someone would pick it up.

Thanks to nostr:nprofile1qqs8rheprycaymhyzysa99dag09u0cuz2p0rxw6uz02qzm8dj4pdn4cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszgrhwden5te0dehhxarj9ejkjmn4dej85ampdeaxjeewwdcxzcm99uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59u2ftwvn who took the job, and now the PR is merged at last! Also, thanks to nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpzamhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuegpp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezuamfdejsul2dhz and nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5 for thoroughly reviewing the code!

Now we will just implement NIP17 in SatShoot via NDK! That's the nostr + bitcoin future I want to build! Feeling blessed.

nostr:nevent1qqstpand5zqyjdxav50v9nc9r00y5n9yeqaw4wezevmnp7l82g5n6ggprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qgsdqnk0xw3s8fvc2t7mdq0d3dqjyqd6shvdyxv6a3eukcngr4324yqrqsqqqqqp28ypvz

#freelance #privacy #grownostr

For nostrapps.com create a PR following instructions:

https://git.fiatjaf.com/nostrapps.com

Then ping fiatjaf, he's busy it can take time to merge.

You should use P2P exchanges whenever you can but I'm afraid the "no bitcoin onramps, only fiat offramps" reality is increasingly true.

In the medium to longterm it won't matter that you operate with lower-value transactions because they keep moving the threshold lower to demand ever more burdensome kyc info for transactions.

Moreover, you will have to deal with sudden account freezes and transaction cancellations if you keep sending money to strangers. It's just a reality of this model, one that cannot be mitigated.

Since the financial surveillance system is increasingly consolidated into one big honeypot, you will not be able to escape with multiple bank account tactics.

One solution is to coinjoin funds or do atomic swaps but that does not erase kyc data. It is a suboptimal solution.

I see three real solutions that remain for freedom-minded people to acquire kyc-free sats:

- Mine bitcoin in a non-kyc way

- Exchange fiat and goods face to face

- Work for it

...and of course you should keep most of your funds in Self-Custody. Maybe some on LN(LSP model makes it easier) and pocket money in #ecash mints.

Realistically you will rarely do option 1 and 2. Working for sats is the best solution and it will bootstrap a freedom economy of Sovereign Individuals.

The best way to get this freedom economy going is in my mind obviously nostr. That's why I am building #satshoot and keep supporting this ecosystem any chance I get.

This is my thesis. What's yours?

#asknostr #kyc #privacy

Nostr will win NOT because we kindly ask a lot of people to "please come over here it's so much better". If this was the best argument I would leave nostr. Hoping that normies someday will be listening is not a good strategy at all.

I believe winning lies in better incentives FOR PEOPLE WITH SKIN IN THE GAME.

It is strictly better to have an ecosystem of apps unleashing features previously impossible and eliminating middle-men.

I focus on building stuff for people that can realize the value of freedom.

Others will be laggards at least, captured slaves at most.

I wonder what assumptions others are operating under.