I think it's just a geo-location issue. njump servers are in western europe and you presumably are on the west coast of the US/Canada right now?

I need a 56k dial up simulator app so I can show my kids what the internet was like when I was a kid. Anything like that out there?

I actually don't believe in divine providence as an absolute.

Granting us free will cost God the life of his Son.

I do believe he uses everything for good though.

I highly recommend running your own AI chatbot. It's really easy on any desktop computer with GPT4all. ttps://gpt4all.io

Here's the "evil Elon" theory to his statements:

Mr. Global's plan to kill Twitter:

1. Make Twitter max free speech.

2. Have the CEO say some "outrageous" things.

3. Woke advertisers leave the platform.

4. Let Twitter go bankrupt because of advertisers' boycott so they can then say: "See, free speech does not have a market"

This is really good! I've had that thought as well.

That's a curious inquisition, sir. But isn't the choice of an ostrich as the mascot an arbitrary choice?

And then he sent his son so he could send his spirit so he could say “This is the covenant that I will make with them after those days, says the LORD: I will put My laws into their hearts, and in their minds I will write them” Eph 10:16

One of the first things I did when I heard of nostr was experiment with a protobuf mapping to reduce bandwidth. nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s later gave me the helpful hint that strfry already maps to flat buffers internally (afair). So that may be the easiest way to go. Just modifying a strfry to serve flat buffers.

Hey your post is trending, which is a good sign.

IMO there should be be a switch to turn nsfw on and off and trending should adjust to it.

And yes, it should be per-post, not per-account.

GM

Have you seen Threema?

Just use Threema

If you want to use a client by a guy who raises sheep in New Zealand assisted by a guy who lives on a dirt road beach in Costa Rica, try https://github.com/mikedilger/gossip/releases

It would be easy to write a relay for the list, that wraps all received messages in kind:6 reposts and tagging them with sequence numbers. It would serve only reposts signed by the relay, the relay could be fully replicated using strfry sync. It’s actually quite trivial. The relay would only serve and store the wrapped messages.

PGP has one key only as well, a mailing list ist in no way more secure than a nostr message.

We should fork FDroid and make a nostr-lightning version of it so that developers can sell their apps there. Actually I might be interested in exploring that (even though I don't like Android's programming interface)

You can have way more than 4 relays.

Initially you don’t even see any of the AmConf relays messages unless you look at their global feed or you subscribe to people writing there.

The AmConf relay cannot fake any of the messages of the users there as they are all signed with the respective users pubkey. It could only withhold messages.

What you see in your feed depends on who you follow (or what feed algorithms you choose in the future). If you use a client that has something like gossip’s relay picker then it will make sure you have at least 2 or 3 relays for everyone you are following.

Hey Paco, I got an email from avianca with that info a couple days ago. I really don't get what they are trying to do.

I believe it only affects you if you "transit" in El Salvador? Since El Salvador is your final destination, you are not in transit.

Also, you should be getting a full refund from your Airline, at least Avianca has offered that to their customers.

https://ayuda.avianca.com/hc/en-us/articles/19744371443355-Airport-Improvement-Tariff-at-El-Salvador-International-Airport

To me it looks like I described in point 3:

Let's say users can mark account migrations in their follow list. They select a user they are following and click a button to add information about a migration. This could be in response to the affected user contacting them out-of-band or because they encountered some migration event like Pablo's kind:1777. In their contact list it will store the old and new pubkeys for a user with some optional explanation.

This means my client can pick this up and show me a little info box or an icon on any note from the old or new key, that will tell me something like "3 of your network are following a new pubkey for this contact". I can then click it to get a detailed view of what the old and new accounts posted, information about who of my network already confirmed it, and why, and I can then decide if I want to signal that I migrated on my contact list as well or if I want to follow both keys for now, or if I want to ignore it.

It's just more information for the user to make a decision, this particular feature would not make any automatic changes.

I would like to know who ended up with the money? It surely must have gone somewhere.

No, I disagree with nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that the UX would not be much different.

With Pablo's proposal, once a user fires of the kind:1777 to initiate migration, if your client supports it, depending on how the client implements it, you would not be seeing the attackers notes, or they would have a red border and warning signs telling you that these notes were written after the valid kind:1777.

Today the client has no way to know. With kind:1777 your client can now warn you about the situation.

Of course it's not a mandatory feature. But it's very central and I think any client that relies on kind:3 or other lists will want to implement it.

The 90 days was an idea to prevent front-running by a few clients, as we have seen in the past, it's how long the fast implementers wait as a curtesey to the others, not a deadline.

RE: NIP-41 discussion at #nostrasia

https://www.youtube.com/live/Nz15SyiwQFk?t=16400

My thoughts on the different ideas discussed is: YES

1. Yes, we should consider implementing what nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft suggests, but we should give clients time (90 days+) from merging the NIP to implement it before clients offer this tool to their users. (reviewers: nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s, nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc)

2. Yes, in a separate NIP we should implement nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6's original idea of a masterkey. It is so good and powerful, I believe it's worth the pain. It would allow holding the masterkey in cold storage. Done right it would allow creating Schnorr multi-sig masterkeys. I would call this a 2.0 nostr account. We should merge the NIP and client's should not start using these until 180 days later (or longer) to give all clients time to implement them before they are used.

Once these 2.0 accounts go live after the implementation grace period, clients should offer their users the option of migrating to a 2.0 account using Pablo's NIP-41 (or another) approach.

3. Yes, we should have social recovery support. It should be a separate NIP and it can be additional to all other migration concepts. Once a key migration is detected, a client should ask the user whether they want to trust this migration. In case the user has out-of-band confirmation of the migration, they can accept it and it will be marked in their kind 3 by listing both old and new keys for the account. Other clients can now pick up on this information and display to their users how many of their own network trust the new key. The user can then decide themselves when they want to start trusting the new key as well. This scheme does not require any history of the old key, as users would simply be trusting their own network. I believe this is much closer to how trust and relationships work in real life as well: you trust your own friends, not who another says are their friends. This could be part of a general Web-Of-Trust NIP that harmonizes how clients calculate and present WoT scores.

The most important aspect in all of this is to clearly mark everything for the user. An account in migration (by whichever scheme) should be marked as such until or unless the user decides to mark his trust in the migration as final.

We should ask the designers to come up with a nostr design best practice UX that clients should strive to implement. nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk

😭 in the stream it’s audio only

Did anyone record this with video?

I fully agree with nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk

P2P is the way!

nostr is the DNS

P2P is how to get the content

#nostrasia

Me: cool I have one hour before bed, I’ll watch the #nostrasia stream

#nostrasia stream: lunch break

🫠

Lol yeah, literally half a million in lighting, dollys, gear, etc

The one on the right is hilarious, just had a good laugh with my kids 😂