BTC Sessions is starting his decentralized onlyfans.
nostr:nevent1qqs9sxn7gle8c3l6358r55ct3jylvsky3qy2w7u76law5xfjznw6h9gpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygqe3yp5u44c7crvwf85tgfvap9prpqkyx40wxp2rajkgwqtn3p8dvpsgqqqqqqs6ldl23
New threads or conversations.
If new threads it's a issue in the don't show too many reposts algo. The reposts appear in the past, it hides some of them. I am not sure how to solve that one yet.
Slowly becoming a real app. A few more rewrites and we can start thinking about v1.0 :)
nostr:nevent1qqs98szdz7z6tgeq750r3q9qtzmpjqcqcfhy9nrsyurwgsxw0pp52rcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygplwuxkt5a8vj5utj6s8tsj8e3wcavc45p4mqmw92qs7wrh5azmyspsgqqqqqqsq56jvr
Let's start with block by picture: "xDBupZD"
nostr:nevent1qqs0hgysl6pq6n9y9skcppqqy697dqufxdlyetz49ed24pmwj2dqatcpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tczyz4fq3ej2cpa4n20s9pqjdt8ju6kdh3mrcs2392hku5v80jvd2zykqcyqqqqqqgvzu97j
Let's start with block by picture: "xDBupZD"
nostr:nevent1qqs0hgysl6pq6n9y9skcppqqy697dqufxdlyetz49ed24pmwj2dqatcpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tczyz4fq3ej2cpa4n20s9pqjdt8ju6kdh3mrcs2392hku5v80jvd2zykqcyqqqqqqgvzu97j
Key delegation: the ability to allow subkeys to speak on behalf of the main key with flexible revocation controls to protect the main key when subkeys leak.
1. It must be mandatory and coded by all relays and all clients. Otherwise, users will see broken experiences everywhere (things appear here as official accounts of a brand but not there, etc).
2. Encryption and decryption is impossible with subkeys. For instance, we can encrypt DMs for all subkeys, but once you do it, you cannot revoke that anymore.
3. Replaceable events and all the indexing around it now must consider delegated keys whose authority can change over time on a simple re-broadcast. The entire indexing now needs to use the DB as a source for the index itself. It gets extremely complicated.
4. Now compound that complexity with the fact that we don't have a time chain on Nostr and things can appear in the past, future and different relays can and do have different versions of what's authorized at the same time.
It's mess, on top of mess, on top of mess.
All because we use raw pubkeys as the main address and not a time-resolvable DID for instance.
Not really. Amber uses NIP-46 to sign and decrypt payloads from your phone. Desktops never see the nsec, only people's phones do. Everytime an approval is required, Amber brings up a popup on the phone.
That can come from your team members or from yourself on a separate device.
It's ok. If they are here just for the feed, it's natural that they are going to think everything else is just a waste of time. We are not here just for the feed, though. The goal is to build everything cohesively in one app.
Broke: Build things so complicated you are the only one that can fix it
Woke: Build an AI to fix things
Bespoke: Build things anyone can rebuild in a weekend
Basta adicionar a sentenca no Security filters no menu da esquerda.
nostr:nevent1qqsvjlngzvpmzrmf5fvnlvtur5epgvnqh6dk53xcfhze4l38v5vjrygpz9mhxue69uhkummnw3ezuamfdejj7q3qutx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4sxpqqqqqqzvvev4z
We implement it, but I don't think the way it was done is that good. Web clients cannot decrypt it because the NIP-07 extension and NIP-46 signers don't offer custom methods for it. Right now only Amethyst and Damus support it. And if somebody creates a version that can get more clients to use, I would be happy to support on Amethyst as well.
Send me good app designs that you are using on the big screen. Right now Amethyst on Fold is just a scaled up version of the app. We can do better, but I don't know what's good in that form factor.
On the list, but we never found a stable Tor library to use inside Amethyst. Much less one that we can control the routes to avoid routing everything through the same nodes.
I didn't check lately, but yes the idea of setting a different route per account or per subscription is key for a more private browsing using Amethyst.
Otherwise, the server can just bundle a bunch of filters together and start tracking users even without a stableish IP behind it
If the lightning transaction happened, the issue is on the zapper service of the receiver. That service creates the zap event and sends it to nostr. If the receiver doesn't have it or has disabled it, or it's offline for some reason, no zap will ever show up.
Let's say there is a company whose sole purpose is to evaluate relay operators and offer relay list recommendations to the best ones.
How much would you pay for that service?
A reliable service that doesn't randomly delete your posts or your zaps, etc.
Yeah, most people just put a bunch of relays and it works for a while until everything starts disappearing and they realize their posts were never there in the first place and half of their relay are not even accepting the types of events they are sending...
Not paying attention to reliable relay lists is a terrible idea.
Fdroid is the same as the Google Play. They centralize everything in the decisions of the few at the top of the group. If they don't like what the app dev is saying, the app doesn't get listed.
That's so strange. Do you use any other client? I wonder if clients are saving to different relays and not syncing up. So, you follow 14 people in one, but the other doesn't update and you follow over there. Now the first gets an update event with 14 less follows.
Oddbean new post about login | logout
Notes by Vitor Pamplona | export