How to best use your financial capital:

1. Find people who are going to develop what you want *regardless of your participation*
2. Fund them

Why would you waste your money if they are already going to do it anyway? That sounds dumb.

Because contrary to your beliefs, your money is worthless. Your money doesn't have a passion. They do.

And if you truly want what you want, the more you keep them focused on their passion the closer you'll bring it to reality.

In other words, the value of your money is not equal to the product they are developing. You don't buy the full company when you invest. The value of your money is just equal to the temporary peace of mind you will give to the team.


The distinction between "It's about me" and "It's about my audience" is a fascinating lens through which to analyze social media platforms. YouTube creators primarily focus on content that caters to their audience's preferences and interests, while LinkedIn creators often prioritize self-centered content, paying minimal attention to their audience's needs and desires. Every other network falls somewhere between these two extremes.

When it comes to Nostr, there will be segments of creators who lean toward audience-centric content and others who prioritize content about themselves, attenuated by the client they use and the type of feed they see from others. The key challenge will be how to assemble the feed the reader wants out of both segments.


Distractions | New Yorker

https://void.cat/d/EtmEDVQ98DeJeLfqsUfuGb.webp


It's very interesting to finally see a client that is designed to transfer mostly, if not always, private events. It opens the door for Nostr to be used in several private communication channels like company workspaces, business transactions, family groups, etc.

GM.

nostr:nevent1qqsddk2kst4459jw6q45qnlmnhf69aapg7yluxsfzq9wwrlxx260jucppemhxue69uhkummn9ekx7mp0qgs84k6jpsav0jmdeqjn2zxlpnsajaw6f8l0m2d4e9t8gjsyn53s4nsrqsqqqqqprvx5u6


Which phone are you using now?


Not yet. You can always block the person, but that will hide all chats and posts from them.


Very cool!


That's a first. Why move away from purple? 🤔


So, we can have AI generated essays, images, music and movies but a feed is too complicated? :)


Whoever solves this in a way that is not just a selection of the bigger accounts wins best client in Nostr 2023.

nostr:nevent1qqsxyzyps06u4mz3j3a4jhs6axnhth3u3dt0unxjcnvpqyquz9w72tqppemhxue69uhkummn9ekx7mp0qgs07f7srjc72ma4skqrqmrm5a4mqdalyyw9k4eu2mjwwr9gtp644uqrqsqqqqqpzkuejh


For now yes. There is a weird issue on material 3 that when using animations the button disappears and doesn't come back. Even though Compose say it rendering the button. It looks like it's rendering off screen :(


### #Amethyst v0.79.2: Performance and UI Upgrades

- Fixes the repeat payment requests when zapping without NWC
- Moves many Toasts to the better-designed Information Dialogs.
- Improves error zap message screens for Material3
- Uses the list's name/title instead of d-tag on the Top Bar
- Increases the performance of the Bottom bar's Notification dot calculations
- Speeds the composition of the Topbar
- Uses the "host" tag as the creator of the stream.
- Moves the check if the stream is online to the viewModel scope.
- Speeds up cold startup.
- Makes sure shared flows don't suspend.
- Updates dependencies

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.79.2/amethyst-googleplay-universal-v0.79.2.apk )
- [FOSS Edition - No translations, no notifications](https://github.com/vitorpamplona/amethyst/releases/download/v0.79.2/amethyst-fdroid-universal-v0.79.2.apk )


Can an app get too big to fail?

Asking for a friend.


It is usually cached and then stops doing it. Do you have space in disk? Otherwise, it might not be saving and then yes it will redownload all the time it's needed.

Was this happening before?


Do you mind sending a video or a print screen of what you see?


hum... do you remember how many items or if you have any non text notes there? I wonder if the list became too big or if there is a heavy note crashing it somehow


Not anymore. Since march, we have moved to a serverless approach.


There is a bunch of very large profile pictures. Like 20 to 50mb each. Especially the animated ones.


Hum... which phone do you use?


Language models for the translation. Each language you see in your feed is a separate file.


Howany crashes and when do you see them?


Which server are you using? Many services are blocked in China if you are writing from there :(


It wasn't that? Interesting. Looking forward to seeing what your mockups :) 🚀


You can see the new line here: https://www.nostr.guru/e/0ac462cc6861670d0b918636467012f512fdfd2d2ed91dfe223c2a62a06bb2ab?relays=wss://relay.damus.io/


Do you mean the space after "release!" on your message? The issue that I have is that you, the author of this post, explicitly added the space in the post. There is a new line there. We can break what the author wanted or keep it as close to the original content. Amethyst is closer to the original intention while plebster tweaks it to make it closer. I always sided with the way the author writes. Because if we start changing how posts look then it doesn't take much to start changing other things.


Go to settings/Apps/Amethyst and hit force stop. That clears the memory. No need to clear the cache.


Sorry, which borders would you like to reduce?


I think so, I am investigating what created it


Hum.. how so? Did it disappear for you?


Click and hold the zap button


That sucks :(


Block/report doesn't work?


My bad, it should work now.


Zaps of zaps on a like of a zap. And everyone gets confused :)


We did in the past,.but it created so many issues that we took it off, maybe it's time to give it a second chance.


Interesting. I don't think we changed the Unicode lately, but I will check it out.


Hum.. either that or a temporary glitch on the image server of those emojis


Are you using GrapheneOS? If so, yes, it's a keyboard issue. You can try AnySoft or GBoard to fix it.


### #Amethyst v0.79.0: Material3 upgrade

Moves the UI framework from material2 to material3, while trying to keep most of our design intact. Keep an eye out for UI glitches.

- Migrates to Material 3
- Add settings toggle to load or not profile pictures by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Updates gradle plugin
- Fixes the inclusion of search relays when they were already there
- Updates translations to Czech, German, Swedish, Dutch and Hungarian

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.79.0/amethyst-googleplay-universal-v0.79.0.apk )
- [FOSS Edition - No translations, no notifications](https://github.com/vitorpamplona/amethyst/releases/download/v0.79.0/amethyst-fdroid-universal-v0.79.0.apk )


Not in the UI yet, but if you connect the phone via USB and open android studio, you can filter for onFailure messages the come from the relay.


nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 : "The business logic [of on-chain transactions] right now is completly merged with your main key. Which is a huge fucking problem."

Nostr kids are like:
https://image.nostr.build/1df4841aa00446b1f203d6d99d91967d541178f542841df06693bbe5868c7714.gif

Go listen to it: https://www.youtube.com/watch?v=juj1AS0x3qY


When zapping in dollars? :)


Do the buttons also disappear or just the images inside the buttons?


We can add it back there. It was moved to the click and hold menu a few months back


Yeah, apologies, we have not separated the two on the hidden post UI yet :(


yep, but I am ok with pre-training. As long as I can use this avatar in every call, it should be fine :)


hum.. interesting. Are you in the latest? 0.78.2? We made a fix in 0.78 that took care of one of these weird playback leaks.

The audio should only come back if you marked the video for the background, in the top right button over the video.


There are two functions on Amethyst Block and Report. Block is just for you. Report let's everyone know your review of the content.


ohh.. I thought somebody would go for a Unified Format type of thing. :(

You should probably specify what happens when Clients filter for replaceables. I am willing to bet very few clients add a limit 1 to get only the latest update. They might end up receiving all historical events if relays are now keeping the entire history and we change the way the filter works.


Ok, this is pretty good.

https://video.nostr.build/c766a09e4549c54bcc05cc7e382e5beafa192a35782afc79b008a4496910e98a.mp4


Lets see if you like the Material 3 version that is coming up. :) Major design switch underneath the app


ohhhhh nice!  It's maybe something we should explore.


Hum... thank you for the report. I will investigate it. Maybe we broke something in the latest versions.


I guess what I am wondering is:

1. Do we want to show more reactions in the natural feed view or stay as is that people have to press the > to see it?

2. When they press >, do we want to have a two-stage UI where you first see only counters and another > shows each author's picture of each reaction type?

Summarizing the 3 most common for the feed UI won't be that interesting as the winners are almost always ❤ and 🤙, which are less meaningful than others.


Were trying to zap Vlady? If that is the case, it's probably because the app is still loading his profile. I will see if I can increase the priority of that task to load them faster.


No space for it. Most phones have tiny screens :)


noStrudel seems to have found the best way to display meaningful reactions: a sequence of counters per reaction type as a bottom row inside the post's frame.

What do you all think?

https://void.cat/d/KbzQPMkCoKkKjWZ4d7Nvpm.webp


Now explain all that in the User Interface without requiring users to read anything (because real users never read anyway)


I will look at what others are doing and follow because I am a sheep and don't have time for this shit :)


Funny enough, the idea that you can see your posts and notifications in two very different apps is not natural to a non-tech user. Most people think whatever they do in an app stays in that app. A Vegas trap if you will.

GM.


Interesting! Something is broken. I will test more tomorrow.


Click and hold the message :)


I only camp at the Sheraton.


Makes sense. Which one are you building?


It's actually quite simple. Both phones have IPv6 and exchange them via Nostr. IPv6 gets rid of most of the NAT stuff. Now all they need to do is to open the firewall.

For that, we can start with a server or a DVM somewhere that people can activate to open each phone's firewall. But after the first few are open, the phone's themselves become STUN servers and start openning connections for everyone else.

There is always a good amount of people online. The idea was to use Nostr's network effects to keep punch through the ISPs firewalls.

I think it works. I just need a lot more testing.


are you trying to do something similar?


Video calls started it, but then I realized we could just send events instead. It works great for DMs and other private events that are encrypted between two people.


What are you looking for? 0xChat also has a version of WebRTC going


It works with servers (obviously). I am testing the server less version. But it might take a while. Lots of firewall traces to debug.


Yep, those seem very low. Amethyst downloads 150,000 events in a regular daily session. :)


I have an Amethyst account 😎

nostr:nevent1qqsvyyhn0uke28fu7jnhchp3yugupd69q4qmjrtn3c6caxlcek7tpzqprdmhxue69uhhyetvv9ujumn0wd68y6trdpjhxtn0wfnj7q3qqny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysxpqqqqqqzwgk9e5


It's the best and most promising client at the moment. Better than all kind 1 clients.


Report? Frankly, it's the same issue we have in the app. We always download and keep everything people tag to you. So, I don't think it is a lot.


looks like making dbs from scratch is what Nostr people do :)


I have been testing fully open inbox relays and I don't think they get spammy with tags on my user. But I'd like to see an operator doing some actual research.


Yep


Regular write relays that only take the events you author.


How many relay operators are focusing on NIP-65 "inbox" relays?

Those are relays that only accept posts that tagged you: replies, notifications, likes to your posts, all zaps to you, boosts, all DMs to you, etc.


The way Mazin is doing, you would only store your own events in that relay. The replies to your event must be saved somewhere else.

But yeah, on "inbox" relays that will receive every reply to your note, I don't think a limit on the number of events makes any sense.


You will need an API to make apps talk to one another. It's similar to how we did between Amethyst and Amber using Android's Content Provider and Intents.


Are you charging per post? That could be a problem. But if it is just a monthly rate, it shouldn't be an issue.

Users will report spam when that happens, so you can delete the event from their account if you want.

If you want to develop relay UIs, I think a nice UI could really help people keep their relays organized with only the info they want.


Just bill to the paid p tag user. I have a lot of need for this.


Is it only for events written by the author or also all notifications?


Hahahahahahaha fuck. Man.. Twitter's design sucks hah? :)


Hummmm... is that space between "1d" and the tree dots always there for you? It's not supposed to be like that 🤔


Fair enough. But now you can put your keys in Amber, which doesn't even have Internet permissions :)


Freedom! :) plus you get the updates faster


Yep. The protocol is just the community's growth engine. It will be less important as time goes by.


Humm.. I didn't know Global was using so much battery. I will check


You can add your recipes, but you have to be on a desktop for now. It's basically a blog post formatted as a recipe. Super cool.


minor


Nobody told me that there are exceptions to the word list. 😅

Right now it removes from everything, it doesn't matter who the author is.


The use case makes a lot of sense. 🚀


🤯 There is a Fork (!!!!) button on http://nostr.cooking


Let's hope we do :)


From the playstore installs yes. I am not sure about the other


Whats your playstore account country?


hum.. it could work


Maybe the app rejects any work until the requested sends the User's metadata record for you to keep :)


Yes. Send me the goodies.


This is equivalent to a dick pick for atheists.


Zoomstr or Meetstr?


General posts are open to the public


Yep, most clients use end-to-end encryption


Thanks! We will figure out what's happening :)


Are you able to install from the PlayStore? If so, we get the stacktraces when the app crashes from the store.


I logged with your PubKey here and it didn't crash. I am starting to think it is some type of encrypted message triggering it


Yep. But the thread management for websockets is so deep into OkHttp that I don't have any hopes of them exposing that error to the library user. :(


I know I have been hunting this down since March. Neither us, not upstream libraries can figure out what's wrong. All we don't is that someone is using a faulty compressor.


They can, there is a bug in a deflate somewhere that crashes android's websocket directly from upstream's code. And since it's running in a thread, the app can't catch the exception to avoid the crash.


The other relays are search relays.


No need to delete them, you can just disable and enable the download and upload arrows


Private keys don't add much to voting. It's the same issue that blockchain people tried to apply their chain to voting. It's cool. But it doesn't solve much.


Yep, that would work.


Yes I did. Interesting idea.


Most of the time you can enforce. And if you loose, you loose. That's the risk of running things as a contractor. That never happened to me, for instance.


Not always. But yes, there must be an agreement somewhere that they agree to that rate. And that agreement can also be on nostr.


I used to bill my clients $300/hr. And they are happy to pay for the expertise.


Imagine using Nostr's video call for meetings and adding a DVM to transcribe the meeting, billing your client in sats as soon as the call ends and receiving payment in a zap.


Skypestr.


The state of Nostr Sept 2023. Ft nostr:npub10td4yrp6cl9kmjp9x5yd7r8pm96a5j07lk5mtj2kw39qf8frpt8qm9x2wl

https://image.nostr.build/9322393fefc54616c3d525d3c121bb7f1b1b3e8ada6a74b1a6056866cdaeb854.jpg


Does it happen all the time with that person?


Nice! 0xChat beat me up and shipped P2P video calls. Let's go! 🚀

nostr:nevent1qqsqufajaac0dam58hrdqhdsj0yxc4p88d4lfz64vgz6kuyhxnvz5fsppemhxue69uhkummn9ekx7mp0qgs84k6jpsav0jmdeqjn2zxlpnsajaw6f8l0m2d4e9t8gjsyn53s4nsrqsqqqqqpuvs7fw


That is very strange indeed. Do you notice if this happens when the Zap split screen shows up?


Its something coming just after some time, right? Maybe a relay is the issue? You can disable half of them to see if it crashes and if it does, then invert and disable the other half. Until we find whats happening.


Gen Y in the streets, Boomer in the sheets.


The boomer in me will always type :) faster then finding 🙂


Obviously, a great logo for the app as usual. :)


I hate the HOME icon SO MUCH. It creates the wrong idea that the home tab is the "main" tab of the app and the user should always go back there. For many users, the messaging tab is the "Home", not the freaking feed :)


There is a huge need for an amazing List management client.  nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc seems to be on it. :)


Yep, yesterday I counted over 1000 profiles without @ in the nip05. There might be more. My local database is quite small.

> Other clients strip the “_@“ for display so they look the same unless you look at the raw json.

Yep, we also do that for those that insert the _@ in the field.

We fix most of this stuff in the UI. Most of the time, it doesn't matter how the Signing app changes the record, Amethyst will fix it locally before displaying. We don't usually send those changes back to relays because we don't want to break the user's experience in the other app he/she is using.

Things you gotta do to keep everyone happy.


Maybe we need a custom feeds event type to setup multiple of these with a combination of options for lists, kinds and ordering in each custom feed. 🤔

GM.

nostr:nevent1qqs2lr0khazycdmk869jg8gfm8xgwgwy20ctlzq7zw8we23q64xk5vqpzpmhxue69uhkummnw3ezumt0d5hsyg9fgd8wze0dqxegd0k0cfm3autst56n05z3kwrj3zycesqdtjy9hcpsgqqqqqqs0rdlxn


Agree. That's why I keep the bare repost. I prefer to hide a duplicated repost in the UI algorithm than have to figure out if multiple quotes of the same post are worth showing or not.


I agree a simple repost has little value, it's similar to a + reaction.


Mostly because some people treat reposts as reminders for those who were not here hours ago. Some people make a habit of reposting old stuff.


Group DMs is the only feature that has been released. Relays tend to hate private stuff, so it has been somewhat of a slog to build momentum.

Maybe the next class of relays will do private events only. Who knows..


Maybe have multiple of these Custom feeds pre-built? The more we learn, the more we realize most people don't have just one feed. They go back and forth between multiple "moods" during the day.


Nah.. that's bad UI. We have to fix 1000s of these little things. This is just one of them.


Yep, but there are hundreds of profiles without the _@ already. For viewing it must be there.


I need to support this no matter what since most people will never write _@domain in their profile edits. But I will see if I can turn them into _@ stuff.


It says that you may use _ as the root identifier, not that you must use it. I always read it as an optional way to do root calls for servers that can't handle "" as a local part. I don't even understand why _ even exists at this point.

I haven't changed nip05 resolution since January, so I am not sure if things have changed.


What's happening?


Using amber or straight private key?


Hummmm.. is it random or on a particular screen?


They are saved in the private part of the mute list. So, they are on relays, but encrypted so only you can read it.


Ohhh sorry. I use nosta for that

https://nosta.me/npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z


Just put the url in the same way you would do it an text note. Most clients render the about me text in the same way they render each post. So it should work. The fancy ones accept markdown, but not all of them.

No one displays html from the post. It's just a security issue with all the potential JavaScript attacks that come with it.


Or just because deleting lists is not as easy. Since they are replaceable events, some relays will return to the previous version instead of deleting. This is still a bit messy. :(


That seems different than what I have but if that is true let's hope we can help them finish the transition.


Which servers are you using for stun and turn?


There is no need to add the _@ if you are root.


But it is a fallback for the p2p if everything else fails.


Yeah that's the easy way to do it. But I think we can do it without coturn. Most of what coturn implements is for the old nat stuff. There days everyone has an IPv6. Só it should be easier.


But then do you keep GiftWraps wrapped and unwrap every time?


Not having a Follow doesn't need to be confusing. It can be as simple as to rename it to "Add to Contacts".


The estimation is that 20% of our users use with multiple accounts.


I am a strong supporter for killing the word "Follow". As it stands today it is as irrelevant as a "Like".

nostr:nevent1qqs0lq9u99llx2ff2zecv7hm637aja05csyqwhye9wqueqju4g7dd7qpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqvzqqqqqqyc6u8mn


The RSS that actually works.


Should each account on Amethyst have it's own database of Nostr events? Or should we have just one DB with everything for all logged-in accounts?

Having one DB for each account enables us to save decrypted content that should only be seen by that account, speeding up the visualization of that encrypted content (like chat messages). However, it also massively duplicates content if both accounts are seeing similar things on public feeds.

Maybe we need a dual-layer database approach. One layer to store everything as it came from relays and a second layer with one database per account to store things in a decrypted fashion 🤔.

Thanks for helping me out.


Ok, this is what I am testing.. Dont take this as a final solution.

First: IPv6. On IPv4, you have to deal with NAT travel + firewall holepunch. With IPv6, the NAT stuff is gone. All you need is a simple STUN server to open the connection.

Second: We can use Nostr to signal people's IPv6+port to one another.

Once that is done, both sides start sendind UDP messages over IPv6 to each other. The first 2 messages should be rejected because of the firewall, but after that the door is open. We try this until we hear a package back.

Now, the beauty of Nostr is that somebody is always online. Which means other phones can behave as STUN servers to open people's firewals more easily.

The goal is to use network effects to avoid the need for central servers. Market participants can add their computers or phones to the pool by just replying the Nostr signaling requests.

It's like a STUN server as a DVM.

Lots to test, but that was the idea.


ohhh yes, that makes sense.


isn't it just a matter of increasing the precision of the filter?


Yep, relays and follows are the same record. If Iris didn't have your follows before you pressed that button then it might have erased everything.


Make it a DVM: https://vendata.io/jobs


what does it take to move your blog to Nostr? :)


Today is the day everyone is releasing stuff.


I think it was fixed in the latest versions. The change to use Amber was blocking the reconnection when switching accounts. Let me know if the problem persists.


Push notifications or just the notification screen?

Push notifications were never there :(


### #Amethyst v0.78.2: Bug Fixes and Perf Improvements

- Forces the presence of the `name` field in kind 0 (NIP-24)
- Disables swipe to change page in the home page until Google reduces the sensitivity of the swipe
- Performance Improvements to preview cards
- Avoids creating nip94 and nip95 events with blank alts
- Adds NIP19 parser to the Account viewModel thread scope
- Fix contact link in relay information dialog by nostr:npub168ghgug469n4r2tuyw05dmqhqv5jcwm7nxytn67afmz8qkc4a4zqsu2dlc
- Add push notifications decryptors for Amber users by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Moves each post's mark as read to the AccountViewModel scope.
- Fix for not clearing the text after sending a new Post.
- Improving the stability of VideoView
- Increasing video memory cache from 90 to 150MB

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.78.2/amethyst-googleplay-universal-v0.78.2.apk )
- [FOSS Edition - No translations, no notifications](https://github.com/vitorpamplona/amethyst/releases/download/v0.78.2/amethyst-fdroid-universal-v0.78.2.apk )


I am buying a Pixel 8 because I need another phone to test our P2P stuff. It's not because I want the shiny new thing, okay? It's about business... it's an investment. Cool?

Great.


nostr:npub160cxmqcwxwf87s30n5qv2xqtdgr3lrszg4eut2k4ck3lzll48hpsqupad5 which client are you using? I am trying to investigate this like of yours: https://www.nostr.guru/e/d6351f0fbeab11d604bfbde759625364bdd755a5cce62f95169603aaad9edf8e


zap splits? :)


It would, but it's work :)


Lots of people complaining that it was too sensitive and would swipe while scrolling :(


strange, i can find you there: https://habla.news/p/npub1pktmatjk0l8vn3jhfuwxaasjd65kn4ye9sce3egup7k993f8fg2q5tpxa6

But yes, your nostr address is not right.


If you do a Nostr book, name it Infinite Ways. There is no scarcity here.


User experience


Habla.news


They have task rabbits, we have task tigers.

nostr:nevent1qqsq0a99r3wk3lfkcnskrln9f0wjjnr7hthrakzjuxdwrces49wxfzspzpmhxue69uhkummnw3ezumt0d5hsyg92ah96qnxm3pj5zc4jdaqmc92c0lakw5fyew3vn5sx6sglm7w4qupsgqqqqqqsr2tcf6


I don't think I will import all the crazy stuff I said over there, but it's now an option :)

nostr:nevent1qqsy6k5375ccgqz80jzv2g69ygx79k5x0d3srjkk6007h8c2lscy0ygppamhxue69uhkztnwdaejumr0dspzp75cf0tahv5z7plpdeaws7ex52nmnwgtwfr2g3m37r844evqrr6jqvzqqqqqqyl8vehy


Habla is quickly becoming the best Nostr Client.

GM.


Do you want just a regular description or something clever?

Amethyst is the Nostr client for Android

Amethyst is the swiss army knife of Nostr apps

Amethyst is the most feature-complete Nostr app


Interesting.. do you remember what you had in the list of words?


Probably


Nice!


Simple. We will have a nostr private key and data model anyway. It's just reusing it for QRs. We don't need to recreate it for PGP. In time, nostr will be so popular that using anything else won't make any sense.


There are few, but real use cases for storing and exchanging Nostr events in paper, inside QR codes directly. An extreme version of P2P privacy.

A legally-binding contract signature for instance, doesn't need to be online or even be stored digitally. The entire signed event can be printed inside a QR code, exchanged offline and erased from electronic existence to only come back online when absolutely needed.

Once you give people private keys and a common data model, the ways to exchange those payloads are endless.


It's essential for Amethyst. Chats provide a sense of community for newcomers that kind1s can't do. But maybe coracle finds it's own way of welcoming new users.


:inky:


We are trying to avoid creating language bubbles like we see on Twitter. The autotranslation should be enough to be able to read other languages, but it is not perfect. It will get better over time.


Yep. We try to not have a any two reposts of the same post in sequence as well but that is a little harder.


Vitor still loves relays 🫶

nostr:nevent1qqszd07glu2nceu6qkqn9utdkaev6eeqd7rmhg838rnxzwysw3ss2zspz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsyg8zenmu7gzq8ulj5jj4kv50ph3muwz43f747vmr9ld2alrjdswgavpsgqqqqqqs8xv8tm


Only display when:
1. I am not following the original post's author
2. I am following but the created_at is at least 1 hr away from post to repost.


In Boston, we say Nostah!


Yeah, I need to separate report and hidden messages :(


See if you can reduce the file size. 10MB is a lot for the poor folks out there in 3G with data limits.


In 2021, 98% of pornography accessed by young adults was internet porn, with a majority (69%) viewed on a cell phone.

https://ballardbrief.byu.edu/issue-briefs/pornography-use-among-young-adults-in-the-united-states#:~:text=In%202021%2C%2098%25%20of%20pornography,viewed%20on%20a%20cell%20phone.


As soon as I figure out a way to not automatically expose people's porn. 🫤


You can now add words that if found in the content of a post, Amethyst will hide the post from you.


hum... was Amethyst reaching your limits? I thought I tested your relays. I can double-check. Maybe we added some stuff that broke it :(


It shouldnt break, just open a new way for exchanging events. But I still have lots to test.

I will likely be doing Bluetooh, WIFI and WebRTC implementations, so there will be 3 new ways to share the event. But one at a time.


Educational content is always welcome!


And we already have push notifications if we need to wake them up again. But our tests suggest that people don't leave amethyst when waiting for a DM. They just move to the feed. Which is perfect for this.


Lots to test yet. We will see if can get this to an interesting level.


Well, the experience I have says otherwise.


Yep, it is pretty standard. :)


Usually yes, but not in a DM conversation. After the first messages, its more likely that both are online.

And we will need both online for voice and video calls anyway.. so..


The receiving user can send to the desktop if they want to. The choice is the receiver's not the sender's.


I am not doing a sync between devices. I am just broadcasting the event directly to the users client.


I doubt. I already have a small version working without a server.


Simple, if two users are using compatible P2P implementations, they can transfer their events via P2P, if not it goes through relays as usual. On a conversation via DMs for instance, I would assume the first DM comes in via relays and then moves to P2P when the person replies. The likelyhood of the two users being online is higher there. Then no additional DM goes through relays anymore, increasing privacy.

Of course, each user can receive the message via P2P and still send to relays for backup, but that is the receving user's choice, not the sender.


I am not going to use the push server for P2P. There is going to be no server. Thats the whole point.


makes sense


30-40 subs, each sub with 30-40 filters, each filter with 30-40 event kinds (some relays block by the number of kinds in a single filter).

That should be enough for everyone.


Between 10 to 12 subs, each with rotating 10 filters each. We have to mix several goals in one sub, which destroys the efficacy of EOSEs.

I wish more relays worked on their sub/filter limits to a more reasonable amount. 30-40 should be enough for most clients, even heavier ones like Amethyst.

The bigger the amount of subs, the better the handling via EOSEs get and thus the smaller the traffic and frequency of filter updates get.


It works great on WiFi. :)


It would be nice to have kind 1063, kind 40, kind 42, 30311, 34550, and 31922/31923/31924 in this order. :)


We already have it :)  Just click on the "Zap >" icon in the new post screen.


nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk how is the support for event kinds going? Do we have a table of which events njump can render somewhere?


Sorry, we don't have much on Amethyst yet. We support Amber and that's it.

The issue is decrypting. Not only private zaps are default (needs decrypting), but also DM messages and every push notification is encrypted. Which ends up triggering the signer multiple times a second.


The new repost profile icons by nostr:npub1aeh2zw4elewy5682lxc6xnlqzjnxksq303gwu2npfaxd49vmde6qcq4nwx are awesome.


Where does Nostr go?

https://void.cat/d/9ztzU7qA3Jkz9qCrw7Bwmi.webp


not yet.


We seve them in the private part of the mute list. It's encrypted to yourself. Only you can see them :(


No need for quotes


Ohhh not yet. I will add this in the next version. Thanks for the report!


Ohh I see. The push notification is our server. You can fully ignore that.


I don't know much about relays. I barely have time to focus in the app 😅


Isnt that true for other relays as well?


I have, but I never installed it.


Yep.


So, I am not sure how useful it is.


I am not seeing anyway for the app to send spam filters to the relay.


Can it run on Android?


What does hyper-nostr have to do with this discussion?


There is a big difference between new requests and spam. New requests are fine. People are never going to report them. But everytime I see an impersonator DMing me, for instance, I report right away. Because otherwise I might fall for the impersonators trap in the future when I am not paying attention.


If you use Obtainium, it's already up.


I can sent it as soon as they define what I need to send


Great. Then I don't need to do anything :)


Sure, then we don't need to do anything on Amethyst.


Unblock


Like unlock did, you have to code everything else.


At least not on itself.


I know. And regex is not going to help you with that.


Not today


But that doesn't even get close to what you are asking.


The filter we released today for Mute works already use regex for that


Interesting


Which is not really that interr5


That would only work if you are searching for things in the .content


No


That doesn't help at all.


I know what regular expressions is.


It's easy to code filters in the app. It's hard to make a language or lots of options to allow users to tweak them to the level this uBlock is doing.


I wish we could just reuse it, but we can't. 1. It won't run on native Android. And 2. The syntax won't work for notes. We will need to re do it.


Understood. But just for comparison that repo that is only running the filter is 3x the size of Amethyst.


That syntax only works for pages. We will need to redefine for Nostr events


Well, that is way more complicated than I thought it would be :)


It would be awesome if there was a way to do it.


Like our filters


You can't choose your own ad blocker filter. It's hard coded by the browser or extension.


Not for spam.


Unless we develop our own spec and a little language to run things on, it's going to be difficult to implement filters that you just download to run in your phone.


In fact, they are the problem. They bring everything, including spam :)


They are used to get things from relays. But those are not useful for spam and other types of app filters


There are no filters for browser-based nostr clients as well :)


It's not an easy task for sure.


You have to create a sandbox to run it.


Its a can of worms


It's one of the reasons we don't even run JavaScript in the app.


If you use a regular language, the filter would have access to a bunch of security holes. The filter could, for instance, read your private key and send it to some other place.


You cannot sent your own filter to strfry. Only if you are the owner of the server.


Well, I am definitely not going to defina a language for this. But if somebody else does it I can follow.


I will see if I can increase the priority. Not a lot of people have asked for those options so the have been in the back burner for a while.


Ohh so just settings to tweak filters. Not new filters.


Thank you nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac!


If people are sending me DMs I don't like, I am marking as spam. It's as important as it gets. Otherwise that message will be polluting my inbox forever.


I don't know what Amethyst Notifications is. There is only a Play version and an Fdroid version. The Play version has notifications and translations. The FDroid Foss version does not.


### #Amethyst v0.78.0: Mute words

https://image.nostr.build/68539c05101a52f9faf18c5ee49a7884222f053e9024884978c9d77c97395a2c.jpg

- Adds the ability to mute words and sentences in the Security Filters screen
- Adds an option in Settings to disable immersive scrolling
- Removes ability to export keys if account is using Amber because keys are not known to Amethyst
- Reverts change to have videos starting from the IO thread again
- Bug Fix for restarting the relay filters when switching accounts after Amber's integration.

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.78.0/amethyst-googleplay-universal-v0.78.0.apk )
- [FOSS Edition - No translations, no notifications](https://github.com/vitorpamplona/amethyst/releases/download/v0.78.0/amethyst-fdroid-universal-v0.78.0.apk )


> these events are sent to identified pubkeys?

On the most basic version, yes. Clients can use aliases as well if they want additional privacy. And those aliases can also be independently registered with relays or simply used to write Spam reports or deletion events.

> What if the recipient's client can't decrypt the event

It doesn't matter if they can or cannot decrypt. If they are listed as a pTag, they are the only interested party in the event. If they are reporting spam, it is spam and can be deleted.


interesting. I have never seen anyone using it like that. Where should I experience this?


I agree with most of this. But I don't think GiftWraps make spam filtering impossible. It's just a different way to do it. Because the event is private, the relay must rely on Reports (or Deletion events) from the author of the p-Tag that the GiftWrap is sent to. Clients can help relays filter these events out when they are in-fact spam.

I think people are waaay to stuck on the current way of filtering spam. Also, I expect to see relay operators that will only deal with GiftWraps. And I would go further to say that they will become the most used relays because most of the information traveling through Nostr will be private in the future.

To me, P2P is now a must. If we truly care about decentralization, P2P should be an option in the toolkit. Relays will always be there as a fallback, but they don't need to be the only game in town.


Then I don't know what the purpose is. What's the purpose?


My bad... I am terrible for naming things :(


Sorry, what filters do you want? I am not sure if we have any additional filter requests these days.


NFTs are awesome. Just not for investment. They can drop the make money pitch and we can all have fun.


I was trying this one a few weeks ago. I still think it is a good idea to start a new data type to define the status between two pubkeys (the edge of the graph).

https://github.com/nostr-protocol/nips/pull/761/files


pet names are more effective when they are private.


They should do that while the app is loading who is participating in those communities. If too many of your follows are participating, the community moves up.


Can you use just name?


We find an issue, we solve the issue.

Devs, please ACK, NACK, add:

https://github.com/nostr-protocol/nips/pull/794


Yep, optimizing for these older chips is harder than I thought it would be :(


Lots of screen approvals? :)


Yes! More zap splits! Let's go!

nostr:nevent1qqsvdju9la8s2d7jdh0r88h39ry0wh6au8vcedg5vlp4a4lz2can8vqpzpmhxue69uhkummnw3ezuamfdejsygrl54h466tz4v0re4pyuavvxqptsejl0vxcmnhfl60z3rth2xkpjspsgqqqqqqsr0fp6t


But, more importantly, we can't have a protocol where people can do "whatever they want" without running into these little issues.


The truth is that in Nostr you have to support what everyone else does otherwise the UX is just terrible. This is just one of the 1000s of little things we need to do to support interoperabilty in the protocol.


That's why we just need a little nip to tell what these things are and when they should be filled. This is not hard. But the lack of any guidance creates all these problems.


You need servers for P2P signaling, yes. But that signaling doesn't need async queues. I also question the assumption that two users are not online. They might not start online, but as soon as one messages the other, both stay online for the length of the conversation. And if you do push notifications, like we do, you can get the other user online in seconds. If both are online they don't need relays at all.


I understand. But I don't have a use for that yet. It's a nice to have in my bucket.

P2P is a must though. The whole point of p2p is to transfer private content without any servers involved.


We save the same value on both displayName and display_name. We also save username and name the same "username" value.

But we display only one name, the first in this sequence: displayName, display_name, username, name.


I agree async queues could just be implemented in Nostr but I don't see a need for async queues at the moment. But maybe I am missing something...


Mostly because many clients break when there is a space in the field they consider to be a username. Like when you @ somebody with a space, it might break them. That's the reason I started filling in the displayName part.


I don't understand why it would have to compromise in either way.

If you trully want censorship resistance, having an option to transfer any nostr event without relays is the way to go. Especially if the event is private.


I use your elastic search :)

I just don't think you advertise it enough.

Also, they need to see the connection with money.

Imagine how many students could do a project in this if it was easy. Maybe an integration with Jupyter?

Anyway, I think there is an opportunity for relays to sell access to data to other devs that can't be bothered building a relay themselves.


What if instead of building it yourself, you offered a marketplace of algos that data scientists out there could create and run on your local db? They could them export their results as a paid DVM and paid you with those profits.


Yes


Build a "originality" index, a "educational" index and a "positiveness" index. Originality should praise people with new types of views/content. Educational should prase people with not necessarily new views but with good delivery of such content. And positiveness should measure how grumpy posts are.


Yes, some relays might not like it, but majority will accept. You can write in the past and in the future.


That's ok, as long as we can turn this into a quick button press it should work.


You can just create the invoice and describe what it will do in the description, like: "extend access until xx/xx/xxxx". The clients just display the invoice and people pay in the same dialog.


Yep, can you already include the invoice in that return?


That's nip65 and is coming as well.


Please develop an automated subscription review protocol that I can integrate with. No one will ever keep going to a relay website to extend the plan monthly. It's just not going to happen until clients make it easy.


All of them. Even push notifications are individually verified.


Mutes should be private


GM.

nostr:nevent1qqs98z3ax8g727vus44p2kywqknp3dxxrxmthv6dcd78z6nr7jvj8ycppemhxue69uhkummn9ekx7mp0qgspcxtmzt9feczptdcwwszmjac0pmrtena4nvetvw406sktyshpvssrqsqqqqqpsmwm85


We will need to go binary for voice and video calls. But for the messages that are just simple nostr events, I am not sure if it makes sense since the event is already in text.🤔


If you don't have brb, you can disable a few (up and down arrows in the relay screen) and see if it still crashes. If it does then disable the other half and see if it stops.


Ohhh interesting.. it looks like this is a relay issue. One of your relays is using compression and that is breaking the app. See if you are using brb.io and delete that.


Google is 60% confident this is Catalan and means that.

And you are all afraid of AI...


It's just about picking the names and writing the NIP. Maybe nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 can use his dictator powers to choose which fields should be used for names and what they should mean semantically. I would follow whatever the NIP guidance says.

This is the typical case of too many cooks in the kitchen. We just need to pick which fields are the right ones and update our UIs.


Mostly because those fields names were never part of any NIP. They are all ad-hoc.


One day...


I neither confirm not deny this picture. And since it isn't a NIP 94 picture, you cannot prove that's me. 😁

nostr:nevent1qqsxyzuwc0wfwz9k0lnvmkeslzx0mvupxrfxncuhd57j6lvw4flgn5cpzpmhxue69uhkummnw3ezumt0d5hsyg9arcvesr3vj8ndcet7jtp9wck23qhtjfedy4u7yg0sxlun0zx7jypsgqqqqqqs6agl73


Which version is that? You can see in the Settings/Apps


I think that would be better


Maybe we find a way to pin posts in communities as well


Sounds strange.


Yep, and we are going navigate those issues as we go. :(


Always. But it's good to be independent from Google.


I think I am the only dev working hard to bring my PlayStore numbers down. 😂


Well, it will be an NIP, so let's hope other clients also support the idea.


Correct. Only private events will be P2P (because they are already encrypted in a P2P way). I just have way more private event types coming up, like legally-binding contracts: https://github.com/nostr-protocol/nips/pull/755


This is your periodic reminder to install Amethyst (and all other Nostr clients) through Obtainium instead of Google's PlayStore.

Just follow this video:

https://cdn.satellite.earth/2bd7e308c1797d64fca09b1d61e9bde24c68dd45e501c7383eff1e85392df11f.mp4


Get the Play edition. It is active by default in that version.


No, I am just testing things out for now. WebRtc seems to work, but I want to get rid of these servers they use for signaling and use giftWrapped msgs in Nostr for that.

I'm might have multiple layers. Bluetooth, WIFI for those physically close to one another and some version of WebRtc for the rest.


Satoshi was like: I better be gone and erase everything.


Yep, it was what started this whole think for me :)


Are you saying that life in the US will be impossible without Nostr? :)


Private DMs, Private DM Attachments, private Zaps, and private reactions on top of Voice and Video calls.


I have not found a reason to use Simplex if you are doing WebRTC. Instead of Nostr -> SimpleX -> WebRTC, you might as well just do Nostr -> WebRTC. It's one less point of attack.


User 1 sends the event to User 2 via P2P instead of pushing through a relay. Then User 2 can send to any relay it wants for backup and to share with other clients the same user uses.

Amethyst would just send it to your own write relays for backup for now. And we could have an option to turn that off for the privacy-conscious users. In that case, no event received via P2P ever leaves the phone.


So, passing over Bluetooth and internal WIFI is very easy (which was my first test a few weeks ago). I just started doing some WebRTC tests and looking at some server alternatives and signaling needs. It works but I am very early in this whole adventure.

I looked at Rendez-vouz as well and I was wondering can't we just pass the signaling through our usual relays instead? Maybe we still need some type of STUN server to get the phone's IP and as long as two users can use different STUN servers, it could work.

What I want to avoid is replacing our replays with a different "relay". If we need to use a server to transfer some info we can just use our regular relays instead to avoid another dependency/attacking point.


This is why I think we can succeed. The relay infrastructure will always be there to be a fallback. The P2P stuff is an additional layer of privacy to be used when 2 phones are able to reliably connect with one another.


dYeah, it's not for public notes. The idea is to focus on private ones, which is generally just encrypted p2p anyway :)


If it fails it goes back to relays. So, it shouldn't have any impact. It's just additional privacy when the user are able to connect to one another.


This better. It's not "minimized access". That's BS.

No server gets access to anything. It's WAAAY better.


Then we will navigate those trade-offs and let users choose what they prefer. :)


You kept telling me to not use relays for private information and then when show that I am not going to use them, you get mad?

Seriously...


I jumped


This Nostr proposal is not that different from what you are saying. The only difference here is the signatures. I was working on a version of a P2P system like you described back in 2008. It is possible. It's hard, very hard, but possible.


No servers (otherwise we should just use relays).

The proposal is to do phone to phone directly.


Nostree is so close to replacing Linktree. They just need to get rid of the user info (just show the links - no one cares about the profile) and boom.

https://nostree.me/npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z/how-to-install-amethyst


Nice!


Well, you have your experience and your assumptions and I have my experience and my assumptions.


Those messages come from regular relays people are using and our service pulls from to deliver notifications. We double wrap them before shipping them out. I am very surprised you are having a hard time with this. This is not rocket science.


We can use one of those methods to transfer nostr events. Let me know if I should look at anything you like out there.


That's what I said :)


I am not seeing anything. It will be P2P.


Interesting. Thats a good idea indeed.


And the async mailboxes will be there when the app needs it. They just won't be used for private events to make sure folks can't track people (or at least can't touch the complete message set).


In the way I see it, it's about the protocol to check if two people are online and then send the event over there, falling back to relays if it doesn't. The most basic version should work for this simplistic scenario. Then we can improve it over time.


What if both users are on Tor?


The visibility of the IP address is what I am testing right now. We can always make it go through an internal Tor implementation, which I am also testing right now. But Tor won't work for voice and video calls later. But I think that use case is less sensitive of IP leakage since the user approves the call when receiving it.

Lots to do yet.


Humm.. I thought you would be happy with the privacy improvement...

The push notification service just double wraps and transmits already signed giftwraps and other events that are coming from relays.

It's the same old push service, but now extremely private.


We are beginning the development process for transmitting Nostr events in a peer-to-peer fashion, away from relays. This will start with Gift-wrapped DMs, Private Attachments, Private zaps, Private Text Notes, and Private Reactions; and will be the preferred transmission choice if both users are online, falling back to relays when they are not. Our Push Notification system already transmitted over 500,000 GiftWrapped Nostr events that relays will never see. With a full P2P this will get even better and will open the doors for voice and video calls directly inside Amethyst. Side-stepping relays won't be easy or quick. And I am sure we will get strong pushback from relay operators. But we will get there. And while this might start as an Amethyst feature, it will be a NIP and other clients will be able to join the privacy train.

Nostr is just starting.


5m
simplex:
- message queues (bad - server can track it by it)
- minimized retention (only if you trust the server is actually doing this - there is no guarantees)
- only queue server sees data (what if the server is selling that data?)
- random source and recipient (same for GiftWraps with aliases)
- dedicated protocol (bad - a general protocol is better to increase the anonymity set)

gift wraps:
- message queues (there is no queue - each packet is fully independent of another)
- retention not limited in any way (correct)
- anyone can see data (in public relays, yes)
- random source and recipient (yes)
- trying to use a protocol for public publishing for private messaging (yes, it's better)


> see when an event shows up first

Go ahead. Just don't forget that my noise server has been live for the past 2 weeks. :)


I am. :)


I think GiftWraps are better in every way. First, relays don't even know if they are messages or not. Relays don't know if this is a new wrap or a rebroadcast of an old wrap. And with aliases, relays don't know who is the target of the message.

Relays do know who is connected. But that doesn't correlate to being the author of the message. Especially when we start rebroadcasting everybody else's message automatically.

Amethyst is starting to make a separate connection for every GiftWrap and I am considering having a built-in Tor connection just for those messages. Each Wrap, each individual message, will be a different connection.


No one is using Tor with SimpleX. And even with Tor, the server can perform queue correlations. Ideally, you have to use a different Tor route for each contact/queue in the application to avoid that.

And in large systems like these queue correlation is more than enough to figure out who is who. All the server needs are a good chunck of users outside a Tor network to start mapping everyone out.

Servers can always count and date each message. And the server can lie about the state of the queue, which creates some interesting points of social attacks.


For me the biggest issue is to have to trust the Simple X server to not track you.


Tested


It should be fixed in the last version 0.77.8


What happened?


Why?


We need more integrations like these.

nostr:nevent1qqs9cuql586evk2fj8thp0trplwg8e6lz9x5ux3lfrgqyuux5j2cy4qpzpmhxue69uhkummnw3ezuamfdejsygrlts45uj9qa8lv5caydvfumwpy386qyquc6c9zqu9fdr92sxxht5psgqqqqqqseudfmd


Fix coming up.


Imagine if Mattermost used Nostr as backend 😱


Google doc with Suggestions support. :)


Copy Coracle's. It's way more user-friendly than Twitter's.


V0.77.7 fixes this :)


Midjourney, but for trending feeds.

GM.


Code is open. Anyone can fork it and create all those versions. I like one client that does it all.


Let's code everything and see what sticks :)


It's definitely possible. Specs are not needed to make software interoperate. It will be beneficial to us all to have fully separate implementations. More eyes on the code and an alternative if the main software goes rogue.


Seriously though. I don't understand this need to display the same stuff everywhere. Clients are different and there is way too many NIPs already. It's fine.

Don't want to display the new editable posts? Not a problem. Maybe somebody will not want to display kind 1s, just replaceables.


There is never going to be a time where that does not happen. Amethyst or not... everytime I go to a different client a see different things. So, better embrace the chaos.


Why do people always assume all clients must implement every new kind? I am not expecting people to implement this one. The feed will just look different in every client, as it SHOULD be. Some will see more, others less, others just a different set of NIPs, etc. There is no such thing as one feed.


Ohhh fuck.. :(


It's ok. As long as we have a stable option, people can decide as we go.


So do you prefer that we just delete the event and send a new one with dates in the past? I initially didn't want to do that because it would create duplicated events in the feed of clients that don't implement deletion yet.


This is pretty cool!
nostr:naddr1qqw8g6rjv4skg6twvukhg6r994mk2c3dwa5hg6pddehhxarjqgs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygrqsqqqa28t93nf3


Do you consider replaceable events an overhead?


The issue with delete is that some clients dont delete yet. So, if their user is only they end up seeing 2 posts. Which I think it is worse than not showing some new kinds yet


People never like anything in the NIP repo :)


Click and hold the zap button to setup the Nostr Wallet Connect with Alby or Mutiny wallet


Let's go! 🔥🚀


Geohash, you can enable by activating the Geo pin in new posts.


No notifications and no translations. That's it.


yep, that part and the notification's stat bar will stay there.


Yep. New note, press the little line chart icon


### #Amethyst v0.77.7: Immersive scrolling

- Animates top and bottom bars out of the way when scrolling by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Removes the need for the split payment popup for only one invoice
- Removes the flickering on chat screens when the bottom bar disappears
- Fixes video keeps playing in the background bug when pressing the bottom bar twice
- Moves reaction calls to the viewModelScope
- Protects against crashing on null contact lists
- Migrates alt descriptions of NIP-94 and NIP-95 from .content to alt tag
- Adds a new line limit to the char limit of the Show More button by nostr:npub1e2yuky03caw4ke3zy68lg0fz3r4gkt94hx4fjmlelacyljgyk79svn3eef

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.77.7/amethyst-googleplay-universal-v0.77.7.apk)
- [F-Droid Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.77.7/amethyst-fdroid-universal-v0.77.7.apk)


:inky:


Decentralization from a single code base.


Not today. But nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 has been thinking on a way to do that. Today this approach would just use the regular replaceable event kinds where most relays delete past events (up to them to keep it or not)


The question is: do you like freedom enough to let other people change their grades? :)


Because it would either duplicate in the feed or show as a reply of the original post all of today's clients.


You can always boost a given version of a replaceable event. In fact, that is how it should be coded. The boost has a e tag for the version and an a tag for the most updated post. The client should show the original version with a message to update to the latest if the user wants.


Mostly because a poll is a consensus exercise. It's meaningless if my client displays a different result than your client. Of course, there are always polls that are just for fun. But the serious ones require additional tooling.


The alternative to this is to simply delete the kind1 post and rewrite it with a created_at date in the past. It would work today as is, but then most people and clients will not even notice the post has changed.

nostr:nevent1qqsf34sss5vdtytuqtywdg7pmkhwuefc3lw6zcd9854lxahlhlqkdmqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qygzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtspsgqqqqqqsqcvjwx


They can already delete the post and rewrite it with the past date. You won't even notice that they changed it. What you are seeing is an illusion. There is nothing blocking politicians and scammers from changing their posts today. This proposal simply creates an easier way while display the last update time for the honest folks out there.


I disagree. I remember when no client showed long-form content. We implemented it blending the new post into the feed and, it took some time, but others followed. Same for custom emojis, etc.

If there is use, it helps people prioritize them. If there is no use, then no one needs to worry about it :)


> base from which familiarity with Nostr begins.

for now... Notes are not the future of Nostr. Believe me, I am a kind 1 author and have an interest in making Kind 1s survive. However, it's very clear to me that this kind 1-main party is not going to last very long. :)


it doesn't matter if they come close or not. Today we already have more non-kind 1 clients than kind1 clients. It's only a matter of time. Kind 1s will be nothing in the future. Messaging alone has 1000x the expected size of "Tweets".


So, you dont accept any events in the ranges of 10,000 to 20,000 and 30,000 to 40,000? Because those are all replaceable.


There is an issue with that. Some clients dont process delete events yet. So, posts get duplicated every time they happen. :(


kind 1 is also not core :)


Sure. And there are 10,000 event kinds in the range to be replaceable, including communities, blog posts, lists, etc. So, sooner or later all of them will have to learn to work with these kinds.


Not for much longer. Now that Twitter and Threads do provide editable tweets, its only a matter of time to get into everything else.

But yes, ideally we show the history of edits.


That's just a bug that we need to fix. :)


False. There are tons of questions I wrote in my profile that we ended up not implementing or implementing a variation of it based on people's feedbacks. This has been happening since January.


Like a Unified Format, type of update?


We already have it when we display Long-form content (Blog posts form Habla news). So, it's not really anything new. :)


So, should habla.news dissapear?


Would you be opposed to using the new kind or opposed to anyone else using it?


Habla.news already does :)


We have been successfully deleting lots of posts since February. :)


You can still use it with kind 1s.


So you are saying the blog system of 30023 is wrong? Because this one is not any different than that.


I am considering enabling Amethyst to write a replaceable kind 1 (new kind:30111) to allow users to edit their past posts at will.

It would work in a similar way Habla News works, but using Kind 1's style of small posts instead of markdown and long-form content of kind:30023.

Of course, we could also write kind:30023 (blog posts) directly, but it would pollute most of the Blogging interfaces with short posts.

What do you all think?


Looks like yesterday's version is a hit! 🚀

nostr:nevent1qqsvd6p5h2pkgjj3vs480gd9qysw9swlcsrfnm8q483gs5mknarfxwcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygxzxrkaxn99eqcchaze9tq9dn0rw5va89wqjpxr06suv59c4498zgpsgqqqqqqsmq5g70


They should. Unless they are not there anymore :(


Is the design good? Bring it back, but in Nostr.


Anyone?

nostr:nevent1qqsr3hn59ffvvgr2u7yep76kgy3uypwvss95qcfkmepjq6kdcmeq75spzpmhxue69uhkummnw3ezuamfdejsygyla3ed27d64fmj4708re3ck55jz4ep4nnwp7pjquj7e0ulwlu9kypsgqqqqqqs67psnf


nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5's new hide top and bottom bars when scrolling is 🚀

GM

nostr:nevent1qqszenjha9lam75tdcvarp68mzqgjsj55248ewerssu8nzvwermjwrqpzemhxue69uhhv6t5daezumn0wd68yvfwvdhk6q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqzzwc9rlks


Even after marking all as read?


What would you do with 1M sats?


from the PlayStore? Yes it should.


Android exposes the filesystem through it's own interfaces that might get in the way. So, when it comes to file system access, I usually don't assume anything.


It's 2023 :)


100 BTC and I will make one.


My bad, it should appear now.


But they could :)


Ohhh you actually want to modify it. Lol. I misread it. Then no. I think clients generally don't allow you to change it.


We need a second, well-funded, fully-independent node implementation from Bitcoin Core.


Yes.


### #Amethyst v0.77.3: Communities, hashtags, and geotags in the Top Bar list

https://image.nostr.build/954a74ed9b597e1c515f44df42b8b7bcff40068e47ed20de565130d3979bfd5f.jpg

- Adds communities, hashtags, and geohashes to the lists on the top navigation bar.
- New Repost profile picture arrangement from nostr:npub1aeh2zw4elewy5682lxc6xnlqzjnxksq303gwu2npfaxd49vmde6qcq4nwx
- Adds a Zap Split view to the master node in the Thread View
- Change nav bar color by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Removes the old user migration from the old preferences database
- Sets up default reactions to be Rocket, Hugs, Watching and Laughing
- Starting a Refactoring of LocalCache away from a Singleton instance
- Fixes blank summaries occupying empty spaces in Long Form content
- Improvements to the rendering of long-form content
- Groups notifications by day first to avoid merging multi-day notification events
- Performance improvements on loading users and calculating reports
- Disable buttons if terms are not accepted in the Login Screen with Amber by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Fixes a crash when login with Amber by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Updates Bengali and Dutch translations
- Removes the follow/unfollow button from the Zap to User view
- Performance improvement by moving zap decryption to run in a group, avoiding multiple co-routines per zap
- Updates Google Play services

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.77.3/amethyst-googleplay-universal-v0.77.3.apk)
- [F-Droid Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.77.3/amethyst-fdroid-universal-v0.77.3.apk)


New repost design


Does it make sense to make some of the UI components available in a separate module for you to use? Like.. you could display all event kinds in the same way that Amethyst does.


They have different meanings for us, though. When the community is on the follow list, you want to see community posts blended into your feed. When they are a bookmark list, you can select the list to see all community follows separate from the main feed.


What are they doing? I dont actually know.


We add communities, hashtags, chats etc to kind3 tags. They can also be added to lists and it should work, but very few people have tested that.


Why using Telegram when Nostr provides similar features?


Or just versions :)


At some point, yes.


It won't change notifications. We are just focusing more into reactions that have meaning. 🚀👀🤑😎😁 are much better than ♥


We are moving away from simple likes. The goal is to make meaningful reactions every time. Simple like and thumbs up are quite useless.


So be it :)


I always do brotli on JSONs.


My user goes from 400MB to 70MB with brotli


The entire thing at once. You want to reduce duplicates (event ids, pubkeys, tag names, etc)


**compressed** json. Otherwise the file is huge.


6 years ago:

https://www.youtube.com/watch?v=Bu5Mtvy97-4


60% of my time today. :)


Made by the oompa-loompas of nipcraft


Sure, you just need to port filters to the content resolver calls (which look like SQLs if you ever used SQLs in Java). I just don't know if the LMDb idea of mapping file pages to memory works is optimized for android's filesystem.


Here :)


It's the punishment for playing silly games :)


Looks like he was logged into as a npub (read-only) nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5


Nice! Let's go!


The intimidating part is maintaining over time. :)


Search. Those are the only 3 relays we know that offer NIP-50 search. Otherwise, things break.


It should be a separate DB app, though.


Things will always work on a single app. However having multiple apps will significantly increase the performance, reduce data usage, and improve the safety of the private key.


Now that we split between Signer (Amber) and Nostr App (Amethyst), who wants to develop the local Relay App?

It's basically the same structure: Use Android's Content Resolvers to communicate between apps in the background. Nostr filters are translated to queries. The goal is to save all posts from the author or to the author on the phone and have some db management actions in place to clean things up here and there.

In that way, we won't have duplicated databases for each Nostr app.


nobody does


Very cool! https://nostatus.vercel.app/


You have to uninstall if you change installation methods.


Early days, but we are going places.

nostr:nevent1qqsgyv5d3gx7etpamt5s0x5l8nx8vk2ufzpeayzf8w8ktru8xlxa7hsppemhxue69uhkummn9ekx7mp0qgsr7acdvhf6we9fch94qwhpy0nza36e3tgrtkpku25ppuu80f69kfqrqsqqqqqpc4c8u5


And now you cannot install Amethyst from anywhere? Or is it just through the APK that is the problem?


Strange. Which phone, OS are you using? It's almost as if the OS didn't remove the app entirely. I am not sure what to do. :(


Habla now has Zap Splits as well. 🚀

nostr:naddr1qqr8xurvd968xq3q07jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2qxpqqqp65wj3xrf2


test


Super strange. I am not sure what is the package this installer is conflicting with. Go to Settings/Apps and see if you can find Amethyst there.


Let's go! :)


Then the app is not uninstalled from Google Play. You have to fully remove it.


Needless to say, we launched with Amber but anyone else can also design a native signer app


Obtainium. :)


Did you login with Amber? You have to have the two apps installed to see the button to log in with Amber on Amethyst.


Yep. Or just wait for the version to be updated in the other place you installed your current version from.


Little video showing how Amethyst and Amber interact.

nostr:nevent1qqspyxge5pvmng6yqg6dznxtve9sr0ghmqrz5c79n2ckmz7wqyjcxdcppamhxue69uhkztnwdaejumr0dspzqateqake4lc2fn77lflzq30jfpk8uhvtccalc66989er8cdmljceqvzqqqqqqy6d2j08

You can download Amber here https://github.com/greenart7c3/Amber/releases/


You have to uninstalled if you installed it from somewhere else, like the Play Store.


Do you have Amber installed? You have to login with that app.


* was made


Recipient and channel IDs are very different things.

Having a recipient doesn't expose the channel setup. As a relay, you don't know if this is a DM, a group message or any other Nostr event. You can't bundle Wraps to decrease the anonymity set as you can when you know all channel IDs.

Because we use NIP-65, GiftWraps won't travel through the same relay set. So, groups are harder to track.

Also, the receiving key in the GiftWrap doesn't need to be the person's pubkey. I have already tested random alias keys that will replace the `p` tag. Each message will look like going to a random receiver.

This will never be achieved by SimpleX.


### #Amethyst v0.77.0-alpha: Amber 🚀

Today marks the beginning of a new era for Nostr Android. A native signing app (Amber) can now store the keys while every other Nostr app focuses on their own use cases. The time of inserting your private key in every native app is over.

Well, at least technically over. Consider this a test release. Bugs are expected.

We hope other Nostr apps for Android follow the same path and stop storing a private key with their own databases. And, hopefully, iOS apps will follow soon.

This version wasade by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 and all zaps to go him.

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.77.0/amethyst-googleplay-universal-v0.77.0.apk)
- [F-Droid Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.77.0/amethyst-fdroid-universal-v0.77.0.apk)


Not really. You have to open a channel with each friend on the relay and use that as an identifier to help their relay distribute the message. So, their relay can count the amount of messages for each channel and can use that to find out who is who.

Their relay needs to know more to correctly distribute the messages.


And clients :)


Sure, but Simple X requires even more trust in their "relays" (because they can see the channel management messages) than this GiftWrapped version.

We can do it, but it would be worse than Nostr + GiftWraps.


I have been testing a zap-per-feature model where people donate when we release new features. If we don't release anything, "we don't get paid" :)

It's actually not bad, considering how small Nostr is right now.

But I know most people only consider "monetization" if it is recurring an "automated". Which is a very Silicon Valley/Venture Capital way of looking at it.

Nostr companies trying to monetize are doing it in the wrong way: holding keys, closing the code, selling data, attaching paid/closed services with their clients, centralizing caching/relays, putting ads, getting a share of transactions, etc. IMO, those are all terrible ways (incentives are not aligned with users) and only serve to alienate their users against them.


Agree. GiftWraps alone don't protect users against their relays. They must turn on a VPN, and the client app must create single-use connections to get to that level of security.

Even with all that, the anonymity set will be too small today to avoid guessing who the sender pubkey is.


Agree. But I am not here to judge relay operators. If they want to offer AUTH to sleep at night, it's fine by me. My point is that they can already guess the sender anyway, so go for it.

VPN + Single-use connections (required) solve the need to trust your own relay set. And that can be a separate/trustless relay service from the trusted model.


Yes, wraps can hide the identity of the signer from the relay too. But that doesn't mean the relay doesn't know who they are. The relay can see all filters and can guess really well who is asking for that data from that IP and use that to guess who is the owner/signer of the GiftWrap.

nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj might add NIP-42 AUTH to make that more clear. The signer of the connection doesn't necessarily mean that it's the writer of the GiftWrap. But it can always be guessed by the relay.

Relays are always trusted services for authors. They know everything coming out of your machine.


Welcome to open source! :) Free and free confuse a lot of people, both devs and users.


Add all kind:30000 with d="mute".

The only issue is that Amethyst only uses the private part of that event. So, you will never see blocks from Amethyst users.

But you can use the Report function.

Users know that Block is private, for themselves only, Report is public.


I am about to merge it on Amethyst.


You can still watch the filters and figure out who is who and what they are doing :)


Same way of the other screens, top bar where it says Global or All Follows.


You can change the list used for notifications on Amethyst but we don't help users create such list yet. They have to use listr.lol to assemble their preferred list.


For sure! Communities are an integral part of a good Nostr experience.


Interesting. Yeah when one fails it's just for that one.


I tried, but many wallets are not supporting it so I ended up rounding to the nearest sat.


It's like a hard shell berry with a huge seed inside. There is not much to each but we liked it.

https://www.beanground.com/wp-content/uploads/2022/03/coffee-cherry-fruit.jpg


South of Brazil, outside of the main producing regions over there.


Don't ask me how I got here, but 32+/-1 weeks is the prime time to eat a coffee fruit out of the tree. Yes, I had a coffee tree at home.

The development of the coffee fruit.

https://void.cat/d/3Kyd4r7uL8fYCNtWF354f1.webp


Hey Pablo, I think there is an issue here. The zap split's 3nd param is a relay, not the weights, which should be on the 4th param.


Replies will be private as well. We just haven't coded that part yet.


What do you mean by simply wallet? Is Alby not simple enough? 🤔


Yep, the main problem is that to "fix" it, we need to break compliance with real markdown... If the follow it to the letter, it is supposed to break. 🤔


👀 private feed test 🚀

nostr:nevent1qqsv8x6j8qx2kz2x5pefdufyy3x8zxte8cepag8nn0jx6h5r7fdruecppemhxue69uhkummn9ekx7mp0qgsr7acdvhf6we9fch94qwhpy0nza36e3tgrtkpku25ppuu80f69kfqrqsqqqqqpkrpvqk


I think there are use cases for both. Let's implement everything and see who wins :)


Sure thing. What's the best way to work with you?


Not really. I knew it would be too big for Flutter/React native :)


Ohhh :) I am not sure. We will see. :)


Each person decides their rate for the paid feed.


People will just gravitate to clients that implement it. Not all clients need to implement all NIPs. Specialized clients should remain specialized.


Maybe when we get to private groups, then yes. Otherwise, just the author of the subscription can send the message.


Not yet. I am testing a few alternatives before suggesting a NIP. This test post didn't use a subscription event. I just sent a private kind1 as if Derek was subscribed.


Yep, the post goes through public relays. It's basically a GiftWrapped DM, but using kind 1 instead of the new DM kind. Replies/likes can be GiftWrapped as well. The app will simply send posts to everybody that paid (have a zap payment to the subscription event) in that month.


For sure.


Feel free to take that screenshot. The project is not a secret :)


Yep, just know that the replies are public at this stage. :)


See if you got it in your main feed.


DVMs, Marketplace, Private Feed Subscriptions. You are witnessing the first push for user monetization in Nostr.

And it's just the beginning.

GN, nostr.


Probably. How much use is in that 1 hour?


We haven't enabled PDF yet. Does anybody still use PDFs? :)


When you are choosing a server for the image. The last one is NIP-95


Thanks! I will merge soon


We already do it when you select NIP-95 in the image uploading screens. However, you need to make sure your relays support these file types or find a specialized relay for NIP-95


Thank you!


Of course not. We are in the US. :)


I better get our Marketplace going.. 🤑

nostr:nevent1qqsrvd8rd022e3dv7w40kufmkz5h6d2h945w77062dfhzpuy9hgmr7gpzpmhxue69uhkummnw3ezuamfdejsygq2wgk2yrsuelc2mlwgc24mp9u40u8qhuedkxxy9q0sx96k658t35psgqqqqqqsxrg5k3


Yeah, I am just waiting for them to support most event kinds Amethyst supports. Otherwise things break :(


It depends on how well the candidate knows about compose. An expert on it can do it in 4-5 hours.


It's about having the best content. Nothing else matters.


Well frankly neither flutter nor react work well with complex UIs. They are great for simple things but they never worked for me for larger projects. And the idea of the same UI working in all OSs doesn't really work for me. Users of different OSs require different UI behaviors.

Or maybe it's just me. At this point, there's too much baggage in my past to give flutter another chance. :(


Performance. But Kotlin is best only for android. So I understand the appeal. However, every time I went with Flutter I ended up switching to React quickly thereafter. React is a better choice. There are more talent, more components/libs and it is faster than Flutter.


Flutter sucks.


Not really. I don't intent on spend absolute any time on iOS and Desktop at all. I find it a huge distraction. But we can adjust the code to help others make those versions if they want to.


New Bounty alert! 1M SATs to whoever can port our code to Compose Multiplatform first and then prepare the version for iOS.

I am happy to help if somebody wants to take the lead on this.

nostr:nevent1qqsgjwe2fgltr296xtdp6nexvg02qun7hrawxzn6qle3urpwsteuzpqppemhxue69uhkummn9ekx7mp0qgsdfx5syw3pmwsm8jpsdj3kn0ejg0vtgju0pdk3r9nq0aasny863hcrqsqqqqqpjcl26d


On new post, there is a zap sign with a right arrow. Just press that and enter a person's name.


When live streams? :)


I don't really know how to solve yet. I definitely don't want to force the space for everything. I think it's only a problem when the next char is part of the bech alphabet. I will investigate


Ohh I think I know what's the problem. People that have a space after their name in their user profile will confuse the writer thinking there is a space after the word but there isn't. Hah...


Hum.. we don't force a space because people want to use without space, like when you cite nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z's stuff. Same for comma and period that can be together with the npub. But that also means that people can post words together with the npub and that will break.


### #Amethyst v0.76.1: Zap Splits

Adds support for Zap Split setup and payment via NWC and manually via individual wallet calls.

- Adds zap split setup
- Adds zap split display
- Adds zap split payment
- Fixes bug when verifying the checksum of LNURLs (bech32) in uppercase
- Allows playback to save any position in real-time and not only after 5 seconds
- Removes potential bugs when the list contains an e tag with an a reference
- Moves deletion and report to be the last item on the dropdown menu
- Moves broadcast up in the dropdown menu
- Updating dependencies
- Updated translations for cs/de/sv
- Forces valid hexes in p- and e- tags when receiving the event
- Stops accepting space as a Valid hex char and requires an even number of chars (padding)
- Forces the ZapRequest to exist when processing the LnZapEvent
- Fixes some long NIP-19 cutting off in notes
- Updates to Finnish, Swedish, Czech and German translations
- Adds Bengali, Bangladesh translations
- Adds Italian Translations
- Updates Chinese Translations

Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.76.1/amethyst-googleplay-universal-v0.76.1.apk)
- [F-Droid Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.76.1/amethyst-fdroid-universal-v0.76.1.apk)


you do you.


The worst part is that even though your dump is signed by your DNA, the poop is not part of the hash function of the DNA and thus Google can change your poop without even telling you. Massive loophole.


Thank you! We are still far from the top performance we could get. Let's hope more people join the project so that we can clean many of these little things up.


In a parallel universe, zap splits took off decades ago with credit cards and each purchase now is just a massive split of every person in the supply chain of a product.


They are not mutually exclusive of one another. You are already the product of aging research. The fact that the majority of humans live more than 40 years is already aging research in practice. We extended from 40 to 80. And now we need to extend from 80 to 160. Our grandchildren will extend from 180 to 360 years. And everyone will benefit. No matter which religion they follow.


> lightning:invoice1&invoice2&invoice3

Good enough for me. How do we get this in front of other wallet devs?


I don't know, but we will need ~200B USD to take a decent crack at the fundamentals of aging. 1 billionaire is not enough.

It's a good thing we can print USD, though :)


I will pass it in a way that will make them better, not as money.


If I end up with generational wealth, I will put every bitcoin I have into aging research.

Aging doesn't need to happen. It doesn't mean we will live forever. It simply means our bodies don't need to decay with time.

We decay simply because we have not spent enough time studying it. We are limited by the technology of our time.


Zap splits work with Nostr Wallet Connect but they are quite annoying if the user is using regular wallet calls. Without NWC, users must go back and forth between the Amethyst and the wallet app for each split. It's quite annoying.

We need a new method to pay multiple invoices in a single call. Lightning devs, help us out here.

https://github.com/lightning/bolts/issues/1111


Yeah that is the worst part. But it's bottom up. The last item changes first, the the second to last, etc. The idea is that users start defining their percentages from the top. And if they are adjusting middle ones the top ones don't change until needed.


Ohh yes. The NWC side seems to work well already. It just about handing several requests in the same second. But I do think we need to make it work for those not using NWC as well. I just don't know what's the best way to solve it.


Nice, let me know when you have some info on how to call it with all invoices


That would help for sure. Or just a simple batch call with all invoices in one. Mutiny loads them in the same screen and a single Pay button approves them all.


Yep, all client for now. It requires NWC. Otherwise there would be many Intent calls to the wallet in sequence, which is really annoying.


Got mine closer to your design. Let me know what you think:

nostr:nevent1qqsvh99qfdc5ajskems6fepp86afdmkr3pshccnjjg32mf90tj63nrsppemhxue69uhkummn9ekx7mp0lyqthn


Zaps splits coming up!

It took me forever to get this UI right, but it was worth it.

https://video.nostr.build/9ac47143fad86098068d68e6fa3fc603da6133901828327c1bb12b30ce8c1e69.mp4


Local Astrophysics ENTHUSIAST?

https://image.nostr.build/a7ef92ef401ff5af60705e23256bd7fd7d9ba6bed47694a1a493eabdbf6f365b.webp


Yay! Let's go!


Maybe we could write Nostr Notes directly in the air-gapped signer after all... 👀

nostr:nevent1qqsqykz4txuwm3ttpl5cgz8mp0528xgeffkql309ncx8g3zcfdglzwcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzp6y2dy0f3kvc0jty2gwl7cqztas8qqmc5jrerqxuhw622qnc2pq3qvzqqqqqqya950dp


Found the bug. Essentially decoders MUST lowercase the prefix "LNURL" to verify the checksum.

The things you only learn in production...

https://github.com/vitorpamplona/amethyst/commit/310db1008ecc6691404882d67e47a3219fbc1375


If you connect your user to them, yes.


Nice! It's very close to what I was designing.. I am not sure if I like the auto adjustment. I may make it adjust from top to bottom. Only the items below the current item get adjusted to match 100%


Yes, lightning addresses always work. Which user was this?


NIP-65 helps, but we are just starting this journey. There is a lot of work to do to decentralize the relay infrastructure.


Very few people understand how leverage works.


I have been pushing for explicit terms of service for quite some time. But most relay operators don't have the time or expertise to design a policy like that. :(


DVMs! I need to better integrate them on Amethyst. But if implemented well, DVMs are a no-brainer for that type of dev.


Zap Split setup UI is a very good challenge for #nostrdesign


Remember: Relays can see your filters. If you are searching for weird/illegal content, the relays you use can always see what the app is asking for and what it got as a result.

And there is no way to avoid this. So, make sure you trust your relays with that type of information.

GM.


I tend to agree.


It's a new DM + Small Group chat system some of us are testing out. Basically, the DM event is encrypted and wrapped into another event (1059) to avoid leaking metadata. The 1059 event is signed by a random key, with a random date, and the only p-Tag is the receiver or an alias pub key to the receiver.

https://github.com/nostr-protocol/nips/pull/686


> Ok, so why can we not just have relays require AUTH for certain kinds and have that in the relay information document? It does what you need.

You can. Like I said, I don't see the point at all, but if it gets you to sleep better, sure. :)

Amethyst implements NIP-42 so it should work out of the gate if you want to test things out.


It's only simple for coders :(


Lots of side effects that must have a UI to fix them.
- What happens when percentages don't get to 100%?
- What happens if you already have a 100% setting and you add another person? Or when you remove it? Does it redistribute or do you manually go there and edit each one of them?
- Do people even want to do this math?


> forcing clients to do NIP-42 and basically breaking the protections of that.

Adding NIP-42 doesn't break anything. GiftWraps already consider the fact that relays receive filters involving the author in the same connection and thus can easily determine who is who from IP. Similar to how SimpleX servers also know who each person is if they decide to track. In both cases, the "relay" is a trusted party.

However, no one else gets to know. That's the point of GiftWraps. It's not designed to add privacy against the relays people use. It's against everybody else, especially when re-broadcasting the event.

I also don't think you need NIP-42 at all. All you need is to enable Delete/Report events to when the paid user is in the p-Tag on GiftWraps. Deletes + reports from the user should help you manage the event without seeing the content. Legally, you are allowing users to have an Inbox. It's their responsibility to report if the see illegal content.

I would love to tell you the relays I am using but I fear you are going to go there and use your influence to try to convince them to abandon their model.


I am struggling with this UI in Amethyst at the moment. I hate the "Weight" for users. But trying to do percent is messy. Anyway, I hope to release a version soon to support this as well.


Too bad. I was a client of Eden from the beginning. But you do you. I was already moving to better relays anyway.


Will fix.


Strange, we don't even process draft events yet.


Could have happened? Sure. Did happen? No.

Why? We have never found a breakpoint in the evolutionary chain of animals that would suggest an "insertion" of a brand new species that has never had a parent in the evolutionary chain.

Yes. Humans, plants, animals, bacteria, and fungii share a common ancestor. We can trace all living organisms back to that ancestor.

If we were seeded, that common single-cell bacterium-like ancestor was the seed. That alien seed is so far away from primates that it would be virtually impossible for two separate evolutionary chains to end up with the same structure as primates, 4 billion years later.


List deleted by owner


👀 https://github.com/vitorpamplona/amethyst/commit/dee231d43abbabdb9c3fc8e32fc736cc31fdc1b3


Any "alien" that resembles a primate is not an alien.


I heard coinbase is going to add lightning.

Which means, they will add Nostr in about 7.4 years.

Winning 🚀

GM.


For sure! Returning a complete nip94 is a very cool idea. Let me know the API details when you are ready.


Well, I can tell it's infinite if your unit of account is BTC. :)


I am not an investor so.. no idea..


Oh no! How are they going to make money now? 😎

nostr:nevent1qqstfftnkqn9lukvgfnqxer83umwemg28cgcvct02lxeandtlpzuuqqppamhxue69uhkztnwdaejumr0dspzqfme70vlgtraactlpe4umnuf4ruatyk3nca3h0f8auw0l5d8lxx3qvzqqqqqqyru0z0z


And I agree. But if Bitcoin is savings, it makes the case for active management even worse. Because now you are not competing with another risk, you are competing with something that has no risk and still beats you :)


I thought I was an OK VC-baked entrepreneur until Bitcoin started showing its long-term ROI...


even worse :)


Ohh cool. What's the best hashtag for that?


If I was an active investor, I would also strongly dismiss the entire Bitcoin idea. It's a lot easier to beat the S&P than Bitcoin's RoI.

I need people to believe Bitcoin will die so that I can use an easier benchmark to estimate stronger returns on and justify the added risk.

Just saying.


I am moving my 15,000 posts around using Nostryfied. So, it looks like I am spamming a bunch of relays right now.

Don't ban me. :)


Are you adding and removing bookmarks in other clients? Most clients only work with public bookmarks and erase private ones as soon as you add or remove an item. :(


The only important thing I want is to know when a subscription has expired and have an invoice readily available to renew it and for how long. I intend to show a popup for the user to pay as soon as a relay sends that payload.


Which is probably true.


Nah, we need to get to a point where we get multiple clients for each "thing".


I see Shorts here and there. It's freaking crazy numbers.

The one I just saw he says that in order to get a paid 5sec spot in his video the marketing agency will need to spend half of their yearly budget on just one video.


I never realized that each MrBeast video is equal to one Super Bowl 🤯

The dude puts up 52 Super Bowls every year.


It will be confusing on Amethyst because people would expect to see the NIP94 content in the gallery, since that's how the UI leads them think about media in general. We will see what we can do.


A non-coder should create the Nostr Client Awards. Get an independent committee of reviewers, put some rules, create some cool categories, raise a prize, and rank us all.

Make us compete. Let's go.

GM.


yeah, I need to update this.. :(

Let me see if I can do it this week.


Mostly because Staking increases the power of the already rich (in that token) over time. Those making decisions on which blocks to add to the chain get a bigger share of those decisions as time goes by.

On top of that, the staker's weight on those decisions is proportional to the number of tokens the staker has. In Bitcoin, for instance, a miner's power is based on their hash rate and not the amount of bitcoin they are holding. They have to spend bitcoin to acquire hash power to try to get more bitcoin. In Ethereum, stakers don't need to spend their ETH to get more ETH

Staking is also not as risky as mining. If a staker behaves minimally well, he/she will never lose their tokens. A miner, on the other hand, can easily go out of business on any unforeseen business situation. A risk-free process is more centralizing.

Separating the power of having all coins from the power of running the chain is a unique feature of proof of work systems. By merging the two powers, Ethereum centralizes control between those who have coins and coders of the protocol. And one might argue that coders and those who have coins are also the same group of people today.

Governance will be tricky.

In my mind, Ethereum is a company. People are, of course, free to buy shares of that company. It might be a profitable trade but it is entirely dependent on the humans running that company. After all, those humans can always decide to dilute shareholders further or have a buyback program in a similar process to what regular corporations or central banks do.

The council of Elders controls the chain. And the Council of Elders also happens to be the richer folks in that system. The rich control the token dilution process and are the first in line to receive new tokens when they dilute them further.


I remember thinking about investing in them and truly believing they could pull it off. Luckily I am a Bitcoiner first.


How is your relay list?


What happened?


It could be a particular post. Keep an eye on it. I am hunting down two crashing behaviours that could be related. Hopefully they are the same and you will receive a fix soon. :)


Yep, unsigned kind 1, sealed, GiftWrapped :)


Gift Wrap them. Nuts should never be transfered publically. It doesnt make any sense.


Like I said, it depends a lot on how you implement.

You can make it backwards compatible by just implementing in a way that they look like fully different accounts or completely break backward compatibility by making these accounts look similar.

I still think implementing communities is way easier than any of this, but I gave up trying to convince you so. :)


Correct. But you also didn't say they must be different. If the default is going to be the same, then it will break the UX. Otherwise it can work.


What you are telling me is that you don't see how not supporting subaccounts breaks these clients user experience. That's fine, but I am telling you, it will suck for them. It will become very confusing if this becomes highly used.

I am saying this because the average Amethyst user has 2+ independent accounts logged into in the same phone. So, I know people will use this if you develop it. The difference is that with Amethyst they are different personnas. They generally don't share the same name or picture. So, It doesn't break the user experience. It's a clean separation.

But they are not different, it will be very confusing for those not implementing it.


Fully separate identities are backwards compatible and will work well in all/most clients.

The Damus' user creating 5 or 15 accounts thinking that people will only see one of them, or a UI that nicely manages together, is not backwards compatible at all. It breaks the UX for everybody else.


Well it kinda is. Every other client will see different accounts and not subaccounts nicely merged together. People will have to follow 5 Wills, one for each topic. They will appear duplicated as if they were different personnas, which is not the expected UI on the Damus user.

Imagine seeing 5 Will with my the same picture and then a 6th as a scammer. Everything gets more confusing to those not merging subkeys as one.

I am not against the idea. It's just not as "free" as you are describing.


The work of composing multiple keys in the same UI is feels larger (fundamentally different architecture) than the work to implement communities. Then users will have different accounts and for each account different sub-accounts, which can all have more sub accounts... etc.

Also, you don't need to support actual moderation for this.


Sure. As long as there is a monthly zap on the subscription, you will receive those private notes.


More or less, are you showing notifications for all accounts in a single view? Same for DMs and chats? Can people message the sub account?

People would send messages and interact normally with the second key and thus either user treats them as fully separate accounts (which every client can do) or clients can try to merge all sub keys in the same profile. But that requires implementation. No one has the later yet.


Yep, but managing multiple accounts per topic gets annoying very quickly. It's hard to visualize people adopting it.


Paid monthly subscription to another user.


Private feed is coming on Amethyst.


No need for new key management. Just a topic people can subscribe to.


Sounds like a moderated community of yourself. :)


It seems to be working well, but we didn't get an audit yet.


0xChat ships sealed DMs (NIP-24). Who is next?

nostr:nevent1qqspt8t72knzsfsz69e0gqap3kzp64n7hejj38j2cxxjap4d9d2qu5sppemhxue69uhkummn9ekx7mp0qgs84k6jpsav0jmdeqjn2zxlpnsajaw6f8l0m2d4e9t8gjsyn53s4nsrqsqqqqqpls2cnw


Some people create some crazy stories to avoid saying they are migrating to Android. 😁

nostr:nevent1qqszldtdqt39fm40wrv0lqwn7rm23yz3cvcke2d398tzcpxr3mk0e9gpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygrkcud2uwjfruweamz8ewshug5umfq38g9mkmn2u9mk6ajru2w2lgpsgqqqqqqshelpey


Nah, there is no shortage of integers. People can create whatever type they want.


just keep nostr.band or noswhere.com turned on for search (the app adds them automatically if you don't)


Some of them are required for search otherwise nothing works. Make sure you have a NIP-50 compliant relay in your list.


Broke: Nostr is a decentralized network of social media applications

Woke: Nostr is the censorship-resistant protocol that powers an ecosystem of distributed, social-network applications

Bespoke: Nostr is a cryptographically-secured information exchange protocol for any application

GM.


I tested it some time ago, but it was creating too many problems. Maybe we should try again. 🤔