Then you know you can just add trackers to the many parts of the code in order to store who is creating Queues and how and when both Bob and Alice connect to the same Queue, map to their IPs and capture their rough locations. Over time the amount of data allows you to de-noise any IP re-use and specify which locations talk to which other locations. By roughly knowing locations over time, you can pin-point an exact user (for instance, if you roughly know where I work and roughly know where I live, you can easily filter your data set to get my exact queues). Knowing an exact user and some rough knowledge of my contacts (say through Nostr or other spaces), it allows you to start mapping out other users in the network. Soon enough, you can safely identify the owner of every single queue.

It's work, but the metadata is there.

Clients can make that work harder by using Tor and other tricks but most people are not doing that today.

Now picture a similar server but without the creation of queues and each time Bob and Alice connect to send a message, they use a separate random key you have no knowledge about. You know IP X is receiving stuff using pubkey A, but the stuff is coming from everywhere. Everywhere can be another client or a relay that is just re-broadcasting the message, which can be old or new.  You don't know if it is the same conversation or not. You can track IPs of each sender and try to group messages by pairs of IPs, but when the IP changes, there is nothing you can use to link the two IP pairs used by the same person. I will look like a new user. Because you have less information, you will need to rely on more external data to identify each conversation thread, which creates more uncertainty on the outcomes.

Now add Tor on top of that.


embrace the chaos!!!


Little secret. In my early days of working as a programmer, I would use a plugin to automatically track how much time I spent writing each professional email to my colleagues in the company. Then I would assemble a spreadsheet with each e-mail, and the time it took to write it, multiply it by my hourly salary, and offer it to my manager to evaluate if it was worth the company's money or not.

Soon enough, I wasn't receiving ANY e-mails anymore.

Best time ever.


And this message would def crash some clients out there.


At that point I can just make up replies in the app. :)

A local bullshit generator. Google just released their Gemini API for Android. Suddently, all Amethyst users have 1000x more engagement than everybody else :)


I think GiftWraps are more like individual Tor messages that can include DMs inside them.

They have the "next node" address that is visible (a pubkey which can be the real one, an alias or a new key every time), but everything else is either random or encrypted.

The GiftWrap event can encrypt other GiftWrap events that together assemble be a full onion route with the benefit being that the final node is the client, not the relay. It would be like never hiting an exit node in Tor.

But we are on early days. I am still wanting for a real cryptographer to make sure our thinking doesnt have any holes in it.


So, just an empty thread screen rendering a single note?


This thing is giving me TouchBar vibes. Let's hope Apple can make it actually work.


just one reply at a time? Or all replies together?


I agree, they are not the same. SimpleX is more private than Signal and Matrix for sure. But the protocol still grants a lot of info to the server.

While Nostr relays also have a lot of info from users, especially if you mix private and public events, a fully private client can make it so that the relay doesn't even know if the computer connecting to them is a user or a proxy. The relay doesn't know if a DM is new or not because date/times are all random. In fact, many GiftWrapped DMs transfers are different encryptions of the same message (or any other private Nostr event), all from random accounts, being broadcasted by bots to generate noise. It fact, that same private client can just transfer directly in P2P if the two phones are online and relays won't even know about it (which is my main use right now)


hehe, sure. Have you run a server? I did.

The protocol requests that servers MUST NOT do many things but that doesn't mean they CAN'T do them. If servers WANT to track, they CAN track. It's on you to TRUST the servers.  The fact that SimpleX servers don't have your profile information doesn't mean they don't know who you are.

For instance, the protocol requests servers to not log client commands and transport connections and to NOT use a persistent DB in the production environment. That is just a request. There is nothing blocking server operators from doing so.

Queue IDs are generated by the server. The protocol requests a strong pseudo number generation. But who knows if they are actually using one for your account. They can just generate sequential numbers to more easily identify you out there and you won't even notice.

The default servers from SimpleX do not use Tor and do not create a new TCP/IP connection for each new Queue/contact, which is against they own procotol recommendations. Their terms describe that they don't associate IP with Queue IDs now, but it's clearly possible. With IPs, you can get rough locations with enough precision to try to identify you with the rest of the data set they have.

And I am not saying anything new or hidden somewhere. SimpleX is very upfront about the need to trust the server you are using.

Don't get me wrong. SimpleX is better than many other platforms for privacy and security, but it still assumes a trusted model with their servers.


You have to install new keyboard. I heard AnySoft's keyboard works


I like the implementation of this feature on Nostur, in the Desktop. You can just open threads as Tabs. It's like a browser, you keep open the tabs you are following and you come back to them here and there. I have 100s of tabs open at the moment. However, It's hard for me to imagine following 100 threads in my notifications, but there may be something in between.


Nice! Congrats on pulling this off!


Yes, the federation can add a label to mark authenticated reviews as an additional data point. But a Review platform can do much better by simply understanding the WebOfTrust score of each key sending the review and discarding those keys marked as spam or bots. Think Google's Page Rank for keys.

For instance, if I go to a store, I would prefer to see reviews by the people I am following, or follows of their follows, than any other user even if famous. This of course breaks the single review score calculations. But I would argue it is a more representative to the quality of the review than a simple average of any other filter over the reviews.


It's hard to compare the two because people usually oversee that Matrix Servers, SimpleX Servers, Signal Servers know who you are to perform the right access controls into your chat rooms. While no one else knows about your messages, the servers do have a LOT of leverage over their users. Any legal action can simply target the server operator, they can turn on several tracking mechanisms without your knowledge and then metadata privacy is pretty much gone.

The goal for the GiftWrap idea is to remove the need for Nostr relays to authenticate users into chatrooms. While everyone can now see GiftWraps being received, they still can't know anything else about it. And since the GiftWrap protocol uses multiple relays to pass messages around, it is extremely hard for any legal action against the server operator to break your privacy.

Now, of course, that all depends on compliant client implementations of the GiftWrapped DMs. Using the same protocol, a client can take the DM experience to such a privacy level (e.g. creating a new Tor session at each message to avoid IP tracking, minimizing nostr filter correlations, etc), that it becomes certainly better than Matrix, Signal or SimpleX. Enforcement wouldn't even know what to target to get your metadata.


Bem vindo. Ninguém fez um Discord em Nostr ainda :)!


It will probably increase the work. But nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 did a great job simplifying the git bullshit for us mere mortals.


It will be near impossible to sync between two clients. You can only control your own messages.


The name matching the command line is king to me.


On GrapheneOS? Change the keyboard. There is a bug between the keyboard and Google's new UI library: Jetpack Compose


Wouldn't they approve only the good reviews, since they are financially motivated to say things work?


Yep, 30000 <= n < 40000, events are parameterized replaceable


1. I would create a new event kind instead of using the generic 30078,
2. I would not make it replaceable, since the federation later pastes into the new event (changes to the original event would not change in the federation's event).
3. I am not sure why the Federation must approve the rating. I would leave reviews to be filtered out by clients.


1 day? Thats quick.


What should be the default setting for dissapearing DMs on Amethyst?

- 90 days?
- 1 year?
- Never?

People can change it of course, but 95% of our users never do. So, the default setting matters


It's one of those NIPs that require you to rethink a few things in your app (like how to cache/index decrypted information). Most devs will take their time to implement. But it is way better than NIP-04 for privacy.


Better verify these other takes. It doesnt make much sense. :)


What do you mean by didnt fix it? You can't see which person is talking to which anymore. The DM kind is hidden away and even date and times are random.


Actually many relays do not accept Tor connections. Hosts generally block Tor by default. The relay operator must disable the Tor block. Damus doesnt use Tor yet so I wouldnt expect their relay to work well from Tor


It shouldn't. 0xChat uses the new DM system. No one knows who you are messaging with, dates and times are all randomly placed and even the event kind is hidden.


What do you mean? Which parts are not private?


Move to 0xChat :)


With nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9mhwden5te0we5hgmmj9ehx7um5wgcjucm0d5hsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5a3m46r  's GitStr you can now send a git patch to Amethyst through Nostr's relays and fully avoid GitHub.

Instructions here: https://github.com/fiatjaf/gitstr
Dashboard: https://patch34.pages.dev/naddr1qvzqqqrhnypzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqqyxzmt9w358jum5nw4h94
NIP: https://github.com/nostr-protocol/nips/pull/997


You can also put the labels behind a private relay only paying customers can access.


We can run multiple bots, each using a different pubkey. People will decide to follow whatever works best for them. We could have multiple algorithms running in parallel.


There are lots of topics (millions?) in the replies. Most people want a mix between very general things like "science" when they don't know much about it all they way to specific things like "sha256" when they are in that field. But we can make it work with whatever the bot outputs.

Maybe the bot can add the 5 most representative labels for each post?


Mostly on topic selection. I'd like to show the labels available to the user and help him/her make new feeds on the things he/she likes. The bot tags these posts and Amethyst just downloads tags from a given topic.


Take a look on NIP 32.


Labels can be done by anyone. You can choose to follow the bot you like.


I really want to see two massive AI labeling bots in Nostr:
- Labels on what each post is about (e.g. Bitcoin, vacations, food, NSFW, etc).
- Resulting labels of sentiment analysis (positive or negative post, etc)

Each Nostr event should be labeled.


Do you kill the app or just send it to the background? Android has a video recording feature in the Quick Settings (slide down from the top) if you want to send a quick video.


Good call, but regular Android also offers side-loading.


Sure. Scaling is the best problem to have. People will figure it out. There is ecash, ark, lightning, liquid, regular bitcoin banking, etc. We have already scaled so much from the early days. We just need to keep going and we will get there.


Definatelly. We don't need centralized catalogs anywhere. With no catalog, there is no way to review, request or enforce the removal of apps the powerful doesn't like.


hum... I have never seen this. Looks like some weird SSL chain issue.

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.


Change your keyboard. It's a bug between Google's new UI (Jetpack Compose) and the autocomplete of the keyboard that ships with Graphene OS.


gotta figure out where would the button go, the UI is quite crowded already. But otherwise it could work.

Tough the app should save the position in the field today. It only doesn't save when the user or Android kills the app and restarts it.


My bad, there is a new bug that was created when we migrated to the NIP-96 servers and the content-warning was not added :(


I really wanted other apps to solve this. But looks like it's not going to happen so we will code it.


Obtainium is automated side-loading :) there is no catalog for Obtainium


Yep, side loading is king.


Turns out the EU is making Apple offer alternative app stores and app side-loading. Which is a good thing. But Apple will still notarize (review?) apps shipped through these stores. Apps must be the same among stores. Devs of third-party stores that use Apple Pay will still pay a 30% fee per transaction. Apps that ship with different payment systems are still required to pay a 17% fee. After 1m annual installs, Apple will also charge $0.50 per install. As far as we know, there are no exceptions for open-source projects. All of these, of course, after paying for your Apple Developer account and only for the EU.

Apple is like: you can have your bigger pseudo-freedoms, we just want money. Lots of it.


Now I know why Apple created their Vision Pro. 😅
https://video.nostr.build/3cb24d2f1634974756f50333ff9337433e73dc999460430eedff31d57e7f6edc.mp4#m=video%2Fmp4&dim=460x458&blurhash=%7CFGkOH%7Epx%5DrYkroeNGoMt7%3D%7C%23lr%3FSfxaRkM%7Bt7ofVsM_V%3FS2WBoMWBt7WBniS2bIt7aft7t6oLRjozj%5DofoLWBofRjWVV%40ozV%40bHWAR*WBoLoffks%3AbFazW%3AofoekCofkCoKbHjZj%5Bj%5BaeW%3BaeWVR*fljYj%5BayaeWqjYj%5B&x=a3830a01f792cb08d596d8b2f9f935371032bc78cf7406f6e0c3288e75d575e5


* nor


Sad retail reality: Everybody wants good skilled service,  but nobody (neither customers not corporations) want to pay for it.


If you use the Play version, it already auto identifies the language and translates automatically. :)


No, for Amethyst I just use the most popular ones. Personally, I have a few that are run by me and a few paid ones.


Relays could identify the language of each note and export a % of notes in a give language in their NIP-11 doc.

That could help users find which relays speak their language. And clients could automatically suggest them in relay settings.


What do you mean by "activated"?


Does it change if you scroll and come back?


It depends on the data plan you have. I use 18-24 relays, but I have "unlimited" data for cheap.


Yes because we won't be able to tell if it's real or not.


Owning Bitcoin doesn't give you voting power over the chain. Wealth will always give you power, just not this particular one. You will have to spend your Bitcoin to buy, use, renew and insure your voting power.


Nice! We just need to find a way to duplicate that behaviour.


If these buttons are not visible on your YouTube, how do you go back on YouTube?


But maybe not all phone manufacturers have migrated yet.


It's not old, per se, but Android has move to these swipes to replace the need for the buttons. A swipe right to left for instance triggers the back button in all apps.


I am getting more and more interested in solo dev careers. Nostr was made for them.

Solo devs push for decentralization like no other. If the protocol can help them push an app/library by themselves profitably, without even having to operate a server, Nostr strikes g̶o̶l̶d̶ Bitcoin and we all win.


Hellthread? *Laughs in #amethyst*


Ohh you are using the old three-buttons design.. are those bottom buttons visible when you go full screen on you tube?


We moved to nostr:hashtag?id=percent encode($hashtag) because of reserved characters in hashtags making the URI invalid. But happy to standardize.


Yes, it's because ours goes complete full screen. You have to click on the image or video to get the X button back. The phone will hide everything for the full screen experience


Not yet. Do other apps offer this? I have never seen this type of change


Also, keep in mind that the relay settings for Amethyst and Damus are different. It's likely that you will see different feeds between these apps. Especially on Global, where both apps have specific activation buttons in each settings.


But Amethyst is not a client designed for NSFW. If you want to see that type of content, look for clients that favor them. There is a lot a client can do to support that type of content. It's just not us.


Amethyst will always hide all NSFW content by default. You can change our filters in the security filters menu option in the left drawer.


Yep, just ask the user if it's ok to share. This is not hard.


Where do you see them? On Global or from your followers? Have you selected to always hide sensitive content on the 3-dot buttons of posts?


Nice! Let's go!


"we introduce a Space-Time U-Net architecture that generates the entire temporal duration of the video at once, through a single pass in the model".

Holy fuck.

nostr:nevent1qqsya5ldfzugypnewnhly3akjm7e4ju8pl807w92tz9jecrkxjfwvaspzpmhxue69uhkummnw3ezuamfdejsygyzxs0cs2mw40xjhfl3a7g24ktpeur54u2mnm6y5z0e6250h7lx5gpsgqqqqqqs6ee2rg


Nostr is quite unforgiving.


Less interesting. It would be nicer to have signed payloads from airlines for each transaction.


Yes, Google automatically tracks all crashes/ANRs from PlayStore installs. No need for any library inside the app. Side-loading requires the dev's own stack or other libraries and services out there. It's not ideal.

Google's one is too centralizing. It would be great if the info was sent over Nostr, publicly. With some sort of approval by the signer (to make sure the error message doesnt expose any private info). Otherwise, most info in the crash report could be fully public.


We need crash reporting libraries for mobile apps that publish their reports on Nostr.

nostr:nevent1qqsy6mmxc5e3jy45dw4was4rhuv4edh7cefkhfrpdz90mgxdrq9823qpp4mhxue69uhkummn9ekx7mqzyqewrqnkx4zsaweutf739s0cu7et29zrntqs5elw70vlm8zudr3y2qcyqqqqqqgt385ct


I think it will depend on how many relays we have. If we go for thousands or millions of relays, then I do believe DVM service will be needed.


Imagine if all Airlines pushed their flight info into Nostr and any client could help agents sell tickets and rearrange flights. You could pay directly in the client and receive a Nostr-native boarding pass.

Lack of interoperability? gone.

Buggy airline apps? Gone.


👀 GitHub in Nostr: https://gitworkshop.dev/


Who is using Amber?


Has anybody made a Jupyter Notebook plugin where we can assemble a story with live queries into Nostr?


Very interesting.. I will check. There are ways for apps to send 2+ statuses. It can be a bug on our side or their side. 🤔


Remember that need for a Google Search for Nostr? Well, https://noogle.lol/

By nostr:npub1nxa4tywfz9nqp7z9zp7nr7d4nchhclsf58lcqt5y782rmf2hefjquaa6q8


There is but you will have to setup the Nostr wallet connect anyway because it would not be safe to store that info on a relay.


Bitcoin is the only true ESG asset.


Frankly, there aren't many active groups to join anyway. The only popular ones are Amethyst users and General Nostr


But that view is also just to find new groups you might be interested. Once you join them, then you don't need to use thet view anymore. They are available in your regular messages view.


Nice! Yep that view still sucks in smaller screens.


Yep. But when I remove either one people using that way complain about it :)


Yeah, that is definitely needed.


Ohh do you mean in the Chat discovery in the third icon in the bottom row or the Joined chats in the second icon?


Interfaces are hard... My mother (72yo) needs to write down action paths from each app on her guide book to remember later. She literally draws the icon in her step by step procedures (like saving a whatsapp image to Google fotos).

Lots of learnings recently and new ideas for Amethyst's UX. Can wait to come back and start coding.


It's easier to just fix the interface. How can we fix it? Do you have a design that you like?


Most computer scientists learn that data completeness (central/global database) and "time chains" (order of events) are paramount to any and all applications. These concepts are so engrained in software development that it is hard to imagine an app without then. Nostr's biggest innovation is the simple idea that neither is really needed at the service/API level of most web apps, leaving the work to be done entirely at the Client level.

nostr:nevent1qqsglpe50drzwtcdavus4mfmn0d06jac3n2t322s8seevx6wj6fzqccpzpmhxue69uhkummnw3ezuamfdejsyg8g3f53axxenp7fv3fpmlmqqf0kquqr0zjg0yvqmjamffgz0pgyzypsgqqqqqqs49et7z


You shouldn't expect different clients to show the same notifications and the same feed. Everyone has their own filters on what and how to show things. On top of that, several clients now use different relay lists and the direction is to be even more dynamic in the future.


You are right. You should update created at. Amethyst might have a caching bug somewhere that shows both events in the feed. I have seen this before.


Also, is Alby down right now? Something is def wrong. nostr:npub1xv8mzscll8vvy5rsdw7dcqtd2j268a6yupr6gzqh86f2ulhy9kkqmclk3x


Hmmm... It might be a low timeout value for connecting with the server. It happens more on a mobile data. 🤔


Very strange. Are you inside Alby's limits? This is what I get. I can debug this in more detail next week (vacations)

https://image.nostr.build/0c823b679745b50e78a4a2483c9020b8403376932533ef362361103f0daf5a09.jpg#m=image%2Fjpeg&dim=1080x1026&blurhash=%7C45%23I%25XK9Xx19pn.t8NWxdEG%255oOI%2C%256NER%24xcNE9GRi%25Mxck7t8a%23R%24jcnpNEocxcR%23s%3DoMR%24ogI*xdaiI%2B%24.R%23WTs%3FR%23-HI%2BWS%24.EHxcs%3DNXxcEHxdaiIm%255NEWAxcR%24-rWTM_ogWTWCj%5Dk9ogxdNEWUxcNEogoMR%24s%3D&x=927601846b62d0feaa874659c7c7f90848d0d23f2a6108524de3634c3f5670a4


Have you set up your Nostr wallet connect in Amethyst (click and hold the zap icon)


Very interesting.


I am getting some failures in resolving your lighning provider. I am not sure why, but the server is not available from here. Maybe the server is too busy right now?


I can help debug this next week. I do think it is some config on cloudflare but we should be able to get to the bottom of this.

It may also be country dependent. Hosting services have different regulations to accept Tor in different countries (e.g. asking hosts to flag/track these connections, etc).


Humm.. yep it thinks you have a larger tablet. Which phone are you using? I may need to increase the minimum size to trigger this. :(


Hum.. I need to check what's going on. It should have been active when we merged. 🤔


There is no way to set relays without changing kind 3 in the old model :(


Yep, many relays do accept it, including Damus'.


Yep, nip 65 is not supported yet.


Yep, 59 is just the wrapping mechanism. The DM nip is here: https://github.com/nostr-protocol/nips/pull/686


Yep. Just activate the incognito icon. They are Giftwrapped and sealed kind 14s.


We tried this and fully disabled it. The proxy just becomes a massive centralization point which I truly think it goes against the decentralization goals of Nostr.


We can try. I don't think it solves the problem but it can minimize it.


Sure. A soccer ball and a coconut also follow the same concept. :)


Sounds like you can't read. Proxy and VPN have NOTHING to do with one another. I am not talking about VPNs.

The removal of our proxy was largely public and listed in our release notes both in my notes in nostr and on GitHub. Its messed up that you think this was a hidden move.


We tried the proxy idea. It's not a great solution. If you use a third-party proxy, that provider can track you around in a worse way than not doing anything and if you use your own proxy/your own servers, then you can track everything a given user is seeing by tracking what the proxy is loading. Both cases are worse in my view than tracking the phone's IP.

My only solution to that has been NIP95 and the tests with torrents we did. But those have their own limitations as well.


You can message yourself from your profile


Does it happen with any photo or just one in particular? Which server are you using?


You can create a chat in the Messages screen. Just press the + button and choose public


Great! I am starting to think there is a way for wifi networks to pretend to have Orbot connected to Tor. Using at the airport, Orbot connects but I can't connect with any relay. 🤔


By turning the proxy off, do you mean turning Orbot itself off? I am trying to test this, but airport network is giving me a hard time. :(


Orbot being off doesn't block any connections. It just goes back to the regular channel.


Very strange. I will see if I can find the bug somewhere.


How do you know the app was bypassing it?


It seems to be working here. Do you know which connections the app is bypassing? I can try to find the leak.


Are you using other clients? They are probably erasing your lists when you follow/unfollow people. If exported and imported then it would erase the follow/unfollow you just did.


Smart 👆

Maybe we need a NIP to define what to hash.


You should always mark as sensitive first. The NSFW hashtag can help other clients figure out why it is sensitive.


Looking forward to have true discussions in every single page in the web.

nostr:nevent1qqsraht2dvargy7tn72gtnsrryhe8txa5wqp2srkfvy2280r6jnrqagpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzpm7r06tl5nadv70yvjm6vxzqpxmucas94n4sch6kk3jd9wvx5c8sqvzqqqqqqy4390y4


Full urls or just partials? Do you add fragments and search queries in the r tag?


We mark all posts with #NSFW as sensitive content by default. Too much porn in it


For now :)


Under construction man..


It seems to be a Damus issue. Damus still uses the super old positional tags (deprecated last march) and ignores markers that were defined on NIP-10. The same NIP defines the marker "mention" to be used in quoted notes and not a `q` tag as Damus expects. Because it ignores those markers, it renders as a reply.


Very cool Nostr-native Discord client with public rooms as NIP-28. It's still under construction fork of Cinny but it's an amazing start.

From nostr:npub1zfss807aer0j26mwp2la0ume0jqde3823rmu97ra6sgyyg956e0s6xw445, nostr:npub18z6qteykzjp4czp6uypnnrz3qv2u8gpkdnazwy2ejhneayj9zpvqzvn6df

https://denny.denostr.com/


Does this work?


The report is saved on relays and each client/relay can create their own filtering options to avoid them. Lots of options out there. From those that just ignore it to those that delete everything that has been reported. It all depends on your relay list and the client you use.


Blocks are private. You will never know. Reports are in your profile.


Use Obtainium for a faster service. PlayStore is always uncertain. Usually it's just a few hours, but they can be very annoying.


Interesting! I have been reticent of "stealing" users from other clients by registering their urls. But maybe it's fine for njump. 🤔


Web3 sucks. :)


No. The idea is to become so big that game makers must publish in Nostr to be seen, similar to how Sony has to publish on Steam even though they have their own launchers.


Somebody should build a Steam store/launcher with a Nostr database. Stop giving control over your games to valve.


Like a super follows where you get notified every time the person signs a new post?


No, kind 4s don't work with the new encryption scheme in a backward compatible way. :(

We are all focusing on a new kind 14 defined here: https://github.com/nostr-protocol/nips/pull/686


Yep, it's an online service. Not really private. :(


Small steps... One after another. 🚀


For sure!


Yep, we don't store anything locally right now.


Cache is already there, but Android can kill the app at anytime and delete everything the app has. We will need some form of storage for drafts.


I need to figure out how to reduce the use of GPU. Most of our jitter is about dropping and creating too many objects in the GPU. :(


New update we just released fixes this :)


#Amethyst v0.83.7: New Signup Screen and bug fixes

New Additions:
- New Sign Up screen
- Reduces the size of the Following icon

Bugfixes:
- Fixes the Bookmark Screen update after adding and removing a bookmark to the list
- Fixes viewModel creation bug for Public Bookmarks
- Fixes bug when creating bookmarks for the first time.
- Fixes bug not allowing to delete a post if Bookmarks are not available.
- Fixes some of the margins in the login screen.

Updated translations:
- Dutch by nostr:npub1w4la29u3zv09r6crx5u8yxax0ffxgekzdm2egzjkjckef7xc83fs0ftxcd
- Serbian by nostr:npub187h9tymz5j6vhyl26kl74yh6yzqzpjec9806w7taey2zefytlmdsttx7v2

Code Quality Improvements:
- Improves dev previews
- Updates libraries and build tools on GitHub Actions
- Updates dependencies

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


We already implement splits.


one step at a time.. We will get there.


Self-custody is king, BUT if you are not up to it... YET, the Bitwise ETF is not only the cheapest but 10% of profits will go to open-source devs through Opensats, Brink, and the HRF.

The only issue is that they use Coinbase as a custodian instead of self-custodying themselves, like how Fidelity is doing.

You can also pay more and go with the memes with $BRRR if you are rich.

I wonder if they will ever show proof of reserves for these.

- Bitwise, Coinbase / $BITB / 0.20%, 10% of profits to Opensats, Brink, HRF
- Fidelity, Own / $FBTC / 0.25%
- Ark Invest, Coinbase / $ARKB / 0.21%
- BlackRock, Coinbase / $IBIT / 0.25%
- VanEck, Gemini / $HODL / 0.25%, for the OGs.
- Franklin, Coinbase / $EZBC / 0.29%
- Wisdom Tree, Coinbase / $BTCW / 0.30%
- Invesco, Coinbase / $BTCO / 0.39%
- Valkyrie, Coinbase / $BRRR / 0.49%, for the memes!
- Hashdex, BitGo / $DEFI / 0.90%
- Grayscale, Coinbase / $GBTC / 1.50%


I will only believe there won't be any federation server signup/review/block when I see it :)


turns out we have lots of little bugs with bookmarks :(


If microplastiscs are the problem we would see enormous lines in the fertility clinics around (people want to have babies but they can't for some reason). That's not the case, though. In fact, we see more and more people going to fertility clinics to freeze their eggs/sperms and not to get help in having babies.

Maybe microplastics are affecting the unplanned pregnancies. But I would argue that is a good thing. No body wants **unplanned** pregnancies.

I am not disputing that microplastics are bad for you or that it is affecting fertility. But the idea that they are the cause of the birth rate collapse is overblown. The effect of microplastics in the total birth rate is tiny.

People just don't want babies. Period.


Nice! I found a bug when there is no bookmark list (code checks bookmarks to make options available in the menu and never renders anything if bookmark list isn't there).


hum.. interesting..


If they can decide to open up, what blocks them from shutting it down again?


Imagine having to beg for an invite code in a so-called "decentralized" social media.

https://image.nostr.build/e7a98e95f2db1fe19cdf42eee48b6b0ea6a58c79e04187b9a1b7ea706c599956.png


Looks like a WoS bug


Not a bug. You can only delete a post of the logged in account.


It's not our call. They need to be able to offer direct links. If they do, then we can convert.


Only if the offer the link to the file directly


Talk about the leak and how Elon can just write a tweet on behalf of the sec if he wants.


It's really a Schrodinger's ETF at this point. Who knew Bitcoin would bring this amount of quantum effects...


I think it crashed! LOL.


What? Did they deleted the file? WTF?


It's done: https://www.sec.gov/files/rules/sro/nysearca/2024/fg-89shlq.pdf #Bitcoin  #ETF


I don't know why you keep saying I don't like adult workers. I never did anything against you... Just because things don't match what you want doesn't mean people don't like you.

And that is a block in Amethyst. People can see you when you block then. You won't see them.


What's the difference between the words block and mute for you?


This week around me...

https://image.nostr.build/b20e2f3337681c0ba9e901e38731d603be33914de52cda492f743e57226a3410.jpg


React Native has been my go to for simple apps in both OSs for years now. It's great for simple things and purely based on JavaScript, which almost everybody can maintain.


ohh that's a bummer.


Doesn't this work? https://developer.chrome.com/docs/web-platform/best-practices/url-protocol-handler

I used it many years ago. It seemed to work fine, but maybe things have changed.


No. Apps that want to receive the call MUST register the lightning: scheme in their app code. Its not hard, but each wallet needs to do this manually.


Most servers dont accept those formats anyway. We are waiting for some good server support.


When the FDroid people gets time to update their catalog. We have no control over that.


That's already there. The block function does that.


Hmmm this is supposed to be automatic. Maybe the nip44 v2 implementation broke this up.


Soon


NIP-96 has been merged! 🚀

File servers, please use this new unified API.

https://github.com/nostr-protocol/nips/blob/master/96.md


Agree, but our opinion doesn't matter. If people use it, we gotta build it.


When Nostr Discord?
nostr:nevent1qqsplzssuptedsqkgtzl9zp6g3pfcwgqnaeqc8sy70lk3my36qczztqpp4mhxue69uhkummn9ekx7mqzypgdjn7zmpvqc6ptqud9gtutrcc6yq9s2z96h9dr80hss4wl9qwkxqcyqqqqqqg6lkgvf


Cool! Basically NIP-95 on steroids.

nostr:nevent1qqsqqqqqgszq87jsec85p8nychgvhs548emydywr4ph9dwfk5pkxhlspzpmhxue69uhkummnw3ezuamfdejsygrmmmmmugka3evlgcqwq3922wsul966nhrayl04svauwldhsjjcq5psgqqqqqqsc9zu2e


Time to fix this, Kieran :)


Yeah. That is awesome. Gotta turn the cache on to make sure results are immediate. But otherwise, great first effort.


We do display PNGs. Most images you see in the feed are pngs.


LLM tokens are the shitcoins of 2024


Many clients have search. But that is not the request here. The idea is to find a homepage JUST for search and nothing else.


When NIP44 dms? :)


So you never used any LLM? :)

The first 10 requests are free, the rest is like a dollar per request.


Way too complicated


#Amethyst v0.83.5: flare.pub support

New Additions:
- Adds support for rendering flare.pub's NIP-71 video events
- Adds support for NIP-75 zap goal events (no rendering yet)

Performance Improvements:
- Improves the speed of the native text contains function for hidden words
- Creating the benchmark build type for testing
- Fixing some of the minification issues in the Quartz module
- Fixes the benchmark test of Robohash
- Initializing the isHidden state for the note correctly
- no need to remember the showProfilePicture state
- Avoiding the creation of modifiers.

Bugfixes:
- Fixing the zap of live streams to go to the Host and not the pubkey in the event
- Add write support for NIP-10 deprecated positional tags in text notes to maximize backward compatibility by nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf
- Relay list crashing when relays are duplicated
- Fixes the loading of reactions and zaps to replaceable events
- Fixes the lack of relay icons in the NIP-44 messages
- Fixes the position of the participant list in live streams
- Fixes reconnecting issue when screens change while the app is offline
- Improves the design of the discovery cards for Live Activity and Chats.

Updated translations:
- Vaz. (vazw) suggested 136 translations into Thai by nostr:npub1tr66yvqghfdgwv9yxhmg7xx6pvgvu5uvdc42tgdhsys8vvzdt8msev06fl
- Spanish, Mexico and Spanish, United States by nostr:npub1luhyzgce7qtcs6r6v00ryjxza8av8u4dzh3avg0zks38tjktnmxspxq903
- Russian by LeonusDH
- Czech, German, Swedish and Portuguese, Brazilian by nostr:npub1e2yuky03caw4ke3zy68lg0fz3r4gkt94hx4fjmlelacyljgyk79svn3eef

Code Quality Improvements:
- Adds spotless
- Fixes the GiftWrap test cases since the migration to v2
- Updates dependencies
- Refactoring some of the old nomenclature of Kind 1 tags.

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


LLMs are waaaay too expensive for this. 1000x more expensive per search.


We need a Google Search for Nostr. Simple page: just the search field. Show result previews in the same way Google does. Click to open in your preferred Nostr client.


Typos are easy. Some of my posts are simply incomprehensible. 😅


You should probably warn them. That's why there is a message button in the error message. Lots of people are using their personal servers or less known lightning providers that might not be ready to receive or just have bugs.


Shitcoins on lightning


Very interesting. Maybe we need to develop a better personal note app for you :)


Many clients support NIP 96. It's just a standard way to upload images/videos based on the hash of the content. Nostr.build and nostrcheck.me also support it.

Then, to make this work, we create a NIP94 to define the owner of the image and add the appropriate zap split as defined in NIP 57. When people reuse the image, we can search for the NIP-94, get the zap split and pay the owner directly.


Miniature dam


What would you like to know?


Hum.. we didnt design the UI to match the NIPs :(


code seems to be available here: https://github.com/shopstr-eng/shopstr/


What's meme royalties? a zap split? With NIP-96 we can search by the hash of pictures and pay the normal zap split in the original post. Is that it?


This happens in many clients. Coracle is also like that.

But I am curious. Why are you quote posting the past all the time?

It doesn't look like a good experience even if the client only shows the next 2. Do people keep clicking to open the quoted post.. like 34 times? That doesn't sound good.


no idea :(


There is some weird bug somewhere on the id hash calculation. Many hashes from shopstr are invalid.


Just reply here: nostr:nevent1qqsdnft5pj2gazwxmatsqrmwn37z8gz4s2ks9xcslfe4au27ftpam6spz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qygzx2l0739jmazvq4yc8908mtev6v5fygpkmp7qey90w0zay0y6t8cpsgqqqqqqsgnpala


Well, I don't know how these new assets work, but it might require an onchain transaction to fund and cash out.


yep. the network costs are 15K sats to get them out, so you have to have more than that.


Sure, I think you can just go to the website that has the balance and send those sats back to the other wallet.


What do you want?


You have to spend from the same site, I think. (like the send and receive buttons)


If they are, there is no way to get around it.


They can be using different contracts.


ohh so the issue is between lightningassets and nostrassets?


I don't think the lightningassets balance is available for Nostr apps.


Is the same 4.84 dollar balance showing up on your Alby account?


makes sense


Sure, the button in the left side of where you type allows you to upload a picture.


Usually that happens when the receiver's  server does not reply to the invoice creation call. It's the receiver's issue


But if you reset to the default relay set, it should solve it.


I will fix it soon


oh! Its crashing because there are two nostr.wine


hum.. whats the npub of the second account?


Yep, Amethyst is not a wallet. It will never show balances. But it does allow to connect with a wallet (like alby) to send zaps, which are always in sats.


On which app? Amethyst doesnt display any assets.


Amethyst doesnt display balances.


Adding their relay on amethyst doesnt do anything with your assets. It just allows you to transfer your notes through their relay.


After you click in the zap, then click on the alby icon, log into alby and grant permission to spend. After you do that you can click return and once you come back to Amethyst, you can hit the same button to save those credentials.


Press and hold the ⚡icon in any post.


On Amethyst, you do that by pressing and holding the zap icon


But you have to setup a separate permission to allow that app to send the payments.


Correct, you can use the alby extension to connect to Nostr in a web client.


ok, just to confirm. The sats you have can be seen inside your alby wallet.


Are you trying to send SATs or another asset?


Or are you trying to send zaps that are on an Alby wallet?


What do you mean? Are you importing it on Alby?


Ok, and are you trying to send via Nostr Wallet Connect?


Or just see the balance?


Are you trying to receive or send zaps?


Setting the relay is not the same as suppoprting. They might be separating assets in different buckets that the Nostr app simply does not have access to it.


Usually the developer must add support for these things directly.


Sorry, does the Nostr app supports those assets?


Does the wallet you are importing into support those assets?


Just send it here


Yep, but they can still see that you are sending them and who is receiving.


Nostr always uses Relays. P2P is possible but people are not usually online, so it has to fall back to relays at all times.


Nostr is not private. Only the DMs are encrypted. All your other information is fully public in relays and being used by  everybody else.


I am not understanding it. What's not the right approach?


If you are not paying your relay, you are the product they are selling to other people. Never forget that.


Nah, just journalistic stuff. Wikipedia is about trying to add everything we can and see what sticks.


I heard he was eaten by an anaconda in Brazil.


The split is great, but I hate client rev-share's with creators. To me, clients should not get in the getting a % of any subscription. It's just the wrong incentive.

Clients should instead have their own "Patreon" subscriptions.


It's looking better folks but keep going!

https://en.wikipedia.org/wiki/Nostr


I did, did you get mine?


Coracle is now compatible with Amethyst's DMs (the incognito icon in DMs). 🚀

nostr:naddr1qqxnzdesxs6rjvfjxqurqvesqgsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsrqsqqqa28zalvec


Does it also include v2 of DMs? :)


It's coming ... :)


Back in May, it was a huge taboo to even suggest moving away from NIP-04.


Not yet.


I think we are talking pass one another. You are talking about components for the webpage, I am talking about widgets to the home/lock screen of the phone. :)


Clearly I have not spent too much time playing in the past 20 years.


This looks like doom


on components? I am not sure if I am looking at the right thing.


oh man... I spent so much time trying to picture a good widget for people's homepages for Nostr. I still don't know what to put there.


No idea. We save the list in the private part of kind 10000. Many clients don't support encryption in these lists, so if you block people in other clients they might erase that section.


Here is how you help Nostr without being a coder: the Nostr page on Wikipedia needs help: https://en.wikipedia.org/wiki/Nostr


Yep.


Only Torvalds. By yelling that his code is better than everyone else's.


No, it's just a lack of time issue :)


Oh yeah, on top of that many relays never actually close anything and keep sending stuff even for past filters. Many implementations kill the entire connection to get rid of old subs. Welcome to nostr :)

But like I said, the processing of reqs and returning events is quite fast, like 30 micro seconds or so. I don't think that is much of a slow down, even in feature phones.

The Compose UI itself is slower than processing.


But I welcome experiments on these. These things are extremely time consuming.


Today it waits 300ms before requesting. We can wait more but the updates start to become noticeable and somewhat annoying like a 10 fps game, even though the screen is at 60 fps.


Not enough space generally. Many relays are still forcing max of 10 filters and 10 subscriptions. That's not enough for all the types of events we are constantly watching. So we have to constantly rotate to fit everything in.


You need to. Every time you scroll, you see a new profile and the app must update the status of that profile. It rarely downloads anything but it must check to see if there was any update to the status.

Same for likes, boosts, reports, zaps, quotes, replies of both the note and the author of the message. We also watch for updates to the user metadata and relay lists of each author in the screen. If it is a replaceable event, then it gets from the replaceable and the normal reference.

If there is an inner event, like a quote or boost, then it does that for both events.


We already reserve :) our cache is quite good for events. What you see on REQs is the app stopping to follow one card you stopped seeing and starting to follow another in the other way of the scroll.


And this is all without using the disk. I added our database for testing and then with the GPU + reqs + disk being used at the same time things get really hard. I need to see if I can build a single texture with most of the icons + low res profile pictures to minimize texture reloading on scroll


But I don't think the slowdown is about the reqs on low end phones. It's about the lack of GPU power. We use the GPU a lot. And many phones have throuble clearing out the memory for textures fast enough on scroll.


I accept suggestions on how to download everything we need without new REQs. Usually we are severely limited by the maximum number of filters on a single subscription and have to split/merge into multiple calls on scroll.


🤔 I will add some error messages in the next release. Then we can start to figure this out


Do they show the loading animation at the end of the url? Are you using Tor and/or any VPN?


Do you see the media when you click the link on the browser?


Many times a day?


Wait, is this an old screenshot, then? I only have 2or 3 reports of this happening. I though you had a new case, but maybe it's one of the old ones?


Can you see the video if I copy it here?

nostr:nevent1qqsvac8et9xrmy3c23n8lvkvr3wm76w4z46c0cqac5067rqtr8le3vcppemhxue69uhkummn9ekx7mp0qgsfh7sdxw5jduu3wr35zw0789fcx88yhuhsxsuzk4wxvy5v0cy6kncrqsqqqqqppy63f5


I don't know. The interface is new on both nostr.build and amethyst (as well as many other servers). We didn't include as NIP94 just because other clients are not displaying it, so these tags were the little hack to keep it working.

But again, how many times do you see these urls per day?


Maybe I need to make it retry to download after a few seconds. 🤔


I am not sure. It could be as simple as an Internet connection issue. If Amethyst can't download it, for any reason, just displays the url. So, it could be anything.


Also, I have only seen reports of this with nostr.build. have you ever seen a url from void.cat or nostrcheck?


Hum.. how common is this? Many images are now like that. It should happen alat every 4 images or so if the url is the issue. If it is more rare, then it's definitely something else. 🤔


They might have recompressed the image. It's a small change, but it is a change.


Humm.. did they change the way it works? I haven't touched the badge code since April :(


It's ok in the sense that there is no better solution. Nostr.build is just one of the image servers Nostr has. In the end they are all the same. You send the picture to a server and you have to trust that server to not go crazy with it.

You can also try the NIP95 option. That sends your picture to relays, but the max size is 100kb :(


If the original post includes a link to a picture, the owner of the server where the picture is hosted can change that image at any time. Ideally they don't do this, but more often than not there are variations in the picture that happened after the author approved the image for the post.


0xChat has it. I am still stuck in the process :(


Thank you both! Much appreciated!


Happy new year, folks! May this new year be full of NIPs for you all.


You can simply delete the post by clicking on the 3 dots in the top right corner


Not yet :(


Nice! You seem to be far ahead of other users. If you don't mind me asking, how much have you donated to your favorite Nostr projects to date? I could use that amount in a model to see if it is viable.


V4V depends on users. If V4V worked, no one would be thinking about other business models. It could work, but people must actually go for it.


Yeah, I need to fix this. :(


Nah, loyalty is for suckers. User whatever is best at the time.


nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s already tried that model. No one liked his nips


The best monetization is the Digital Costco model.  You pay a membership to Amethyst and we bring you the best NIPs.


Voice conversations with an open source in-device LLM model are a game charger. It's difficult to picture a phone without a powerful NPU in the future. We wouldn't open Amethyst anymore, we would just ask: How is Nostr doing?


You are the least capitalist of the capitalists I know. :)


Testing video posts with direct urls


reply test. :)


test


Then don't watch it. 🤷


Dev/design costs grow exponentially with the how good the app is. It costs 1x to get to 50% good. Then 2x for 75%, 4x to get 87.5%. 8x to get to only 93%.

That's why most Nostr apps tend to be largely single-dev and rough at the edges.


Definitely no ads. We will figure out a good monetization scheme in time.

The issue is that things get much more expensive when there is a financial transaction and some legal agreement to have things delivered to the user. It's funny how much the legal stuff changes the numbers.


Nice!


Yeah! Lists everywhere! :)


Let me know if it doesn't work.


Just remove it from your relay list


If it was on me we wouldn't have URLs at all. :)


Why? We have hundreds if not thousands of images already. Most things are working really well.


Thank you! It's very rare occurrence.


Thank you!


Copying a url with all the tags in it is key. Lots of people copy the url from somebody else into their posts. If we place these tags in any other location, they are not going to be copied to the new post. In this way, users keep spreading the improved experience even in clients that do not support these tags.


NIP-94 is not enough. It should have been either NIP-95, where the image is stored on relays and can easily be moved around without changing its event id or NIP-96 where you send the same file to 10+ servers to be able to swap their urls if needed.


The decentralized protocol forgot to decentralize media distribution.


There are no FOSS language models to run in the device yet. Maybe one day.


It's not a server issue. The extra parameters are needed to create previews and prepare the UI for the size of the image. There are multiple ways to do it, but in the end they will always be there.

It's better to have them in the URL directly if people are copying urls from post to post. Then they copy everything together.


The user with their battery. It's all in-device. No server is used.


Was a video playing in the background? That's the only service we run that is not stopped when the app is paused 🤔


Agree, gotta reach at least 20% O to have an ignition via either abiotic or biotic means. Venus is a great example.

Latest research points to both been a lot more rare than what we once thought. Very interesting distinction between life (no fire) and civilized life (barbecue 😎).

Balbi, Amedeo, and Adam Frank. “The Oxygen Bottleneck for Technospheres.” arXiv preprint arXiv:2308.01160 (2023).


Correct. But electricity is not fire. :)


Fire can't exist without life. Even though there are water in several planets, fire is exclusive to earth (Sun is plasma).

Let that sync in.

GN.


I definitely prefer NIP94, which is available since March on Amethyst. But here we are...


This position doesn't make any sense. Receiving clients can't control which type of URL the writing client is using. You have to deal with whatever comes in or your user will not have a good experience. Agreeing to use a simpler url scheme doesn't solve anything because it just takes one client to break it.


It begs the question of why it's breaking. This is a normal url. It shouldn't break anything. If this is breaking, lots of other urls are also breaking.


Google's camera doesn't pass the link along to other apps. Only a very few select apps (like browsers get that feature). :(


It's the NIP 54 proposal. It adds a bunch of tags to clearly define the content type, facilitate previews and size calculations before downloading the media.  https://github.com/nostr-protocol/nips/pull/521


There button to scan is on the bottom-right of the menu drawer. Granted, I need to place in a more visible location.


Charles H. Lineweaver et al, All objects and some questions, American Journal of Physics (2023).


This one works well. 🤔


If you open on QuickTime it will tell you that it cannot play part of the file :)


In nights like these, I'd like to offer the chart that includes everything we have ever scienced.

Merry Christmas.
https://image.nostr.build/c7242b29f2ba899c4c734622ac84a6048035b67a774073971a24859ce9895ab0.jpg#m=image%2Fjpeg&dim=700x780&blurhash=%7BbPZJynN%3F%5EyD-%3BjYofM%7BV%40kCozV%40axf%2BayjZtkkCs%3AenRjR%2Bjuoft7oLRjWUbIspo0W%3B-%3BfkM%7BRjV%40s%3AbHa%23kCWUe.s%3BofRkR*j%5B%25Mj%5DV%40aeWBj%5Bj%5Bj%5BkCf6ayj%5DWBayofoLxubHV%40aeWCayaya%7C&x=cebb3b45867cce35f11740da3ad44d8c280582edd3582c3803c977e5326341a7


Bizarre. Even on the Mac it only opens part of the file.


Android 14, Pixel 8, no browser seems to be able to play it. If you download the file and open locally you can hear the audio but no video. I can check on more phones on Wednesday


Is it just me or the url doesn't open on the browser? https://v.nostr.build/BLDP.mp4


nostr:npub137c5pd8gmhhe0njtsgwjgunc5xjr2vmzvglkgqs5sjeh972gqqxqjak37w  can you check the link here? I am not sure if this uppercase path is what's supposed to be. 🤔


Something is off here. Is the url path supposed the be in uppercase like that? I can't seem to be able to download it if the case is kept. 🤔


We are only using the download url that comes from the NIp 96 API for now.


It usually doesn't repeat. The app calls it, gets a 403 and if it calls again the image comes. I am not really sure why. But since the hash is also frequently not matching, it could be something on your caching system.


Of course not. But that isn't the problem. The problem is that the server is replying with 403 here and there. I still don't know why. It feels quite random. Most images work fine.


NIP-96 is the new API for generic image/media servers. We shouldn't go back to hardcoding several different API just because of hiccups here and there.


The only way to trully solve this is to either have a server that can provide image sizes or download everything before showing on the feed. There are hacks like the imeta tag or nip54, but those depend entirely in the writer client including them, which is not ideal for the receiving client.

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


Nostr.bulid is quite spotty lately. Maybe something to do with the new NIP-96 interface.


You can click and hold the like button to add or remove emojis that you like to react. Then you can add several heart options from the emoji list.

Now, likes by themselves are very lame and don't mean much for those receiving them. We strongly recommend to choose meaningful emojis that communicate your reaction to a post better.


Global doesnt mean equally distributed. There are many more Japanese users right now than the rest. So, you will get many more post in Japanese than any other language. But the global feed comes from your relay list. You can try to choose relays that have more posts that interest you.


Wow.


I check for opengraph's info for preview cards in every url. Thus, I end up hitting the server even for images and videos. When that happens, you also receive the content-type of the file in the HTTP header. I use that to determine how to render the media.

I still check extensions first, but that has proven to be problematic (some image servers serve different formats, other urls have query params that affect the discovery and many don't actually offer extensions at all).


Try using Obtainium. The side loading installer has been quite difficult to work with recently. Obtainium has a separate installer.


That's strange. Did it actually install? It looks like it's not installing at all. It does say v0.83.1-play in my device.


Nip44 is used by GiftWraps, which is used by nip 24. :)


No. The encryption is not backwards compatible so each other client will have to decide to support it or not.


People want to forget v1 existed so there is no good doc to show. But essentially, v2 fixed some issues with message length (smaller messages would yield smaller encrypted bytes, which is not ideal). We also got rid XChaCha because it is not standardized and the added protections aren't needed inside Nostr messages.

v1: XChaCha20 with sha256(parity + ecdh) as a shared key per conversation
v2:  secp256k1 ECDH, HKDF, padding, ChaCha20, HMAC-SHA256, base64

v1: https://github.com/coracle-social/nips/blob/7f98a7b8849c16f9d324e0ea15db4efda0ee84fb/44.md
v2: https://github.com/nostr-protocol/nips/blob/master/44.md


It's just an encryption upgrade for DMs. It's now audited.


Only us for now. But Gossip, Coracle and 0xChat are working on it.


Good catch


It will be there. It helps with previews and to make sure server doesn't modify the image after the author has approved.


What do you mean? The url is always part of the post.


#Amethyst v0.83.1: NIP-44v2 DMs are up!

New Features
- Moves DMs to the audited NIP-44v2
- Adds support for NIP-31 alt tags
- Adds a k-tag to reactions
- Adds i18n for error messages when uploading images

Performance Improvements:
- Improves the performance of Robohash
- Add less memory-intensive timeAgo calculations and translations
- Uses primitives instead of the wrapped object in several places
- Moves to a less memory-intensive way to write and send filters to the server.
- Refines recompositions of routes and bottom icons
- Avoids the creation of new sets when looping through cached maps of User and Notes
- Avoids recreating the EOSE array when changing filters
- Reuses SessionToken for all Playback connections
- Improving the memory use of concurrent hashmaps and immutable collections
- Reduces the use of remember for fixed UI modifiers

Bugfixes:
- Detects URL mime-types by pinging the server instead of relying on the url's extension
- Fixes bug with cropped joinToString assemblies of relay filters
- Avoids Concurrent Modification Exception on the EOSE markups
- Forces nip95 to be under 80Kb to make sure relays can receive it
- Fixes bug that error messages wouldn't show an error when uploading images to the reels page
- Fixes post video dimensions when the user has selected not to load videos automatically
- Updates dependencies

Updated translations:
- Chinese by @ra5pvt1n
- Finnish by nostr:npub1ust7u0v3qffejwhqee45r49zgcyewrcn99vdwkednd356c9resyqtnn3mj
- Hungarian by nostr:npub1ww8kjxz2akn82qptdpl7glywnchhkx3x04hez3d3rye397turrhssenvtp
- Dutch by nostr:npub1w4la29u3zv09r6crx5u8yxax0ffxgekzdm2egzjkjckef7xc83fs0ftxcd
- Tamil by nostr:npub1q6ps7m94jfdastx2tx76sj8sq4nxdhlsgmzns2tr4xt6ydx6grzspm0kxr

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


Absolute safest is hard to define, but it is pretty up there. Now, keep in mind that NIP-44 is just a really good encryption scheme. Much better than NIP-04 for sure. But each NIP can use it in several ways and the final security and privacy will depend on how it's used in each event type.


It means the hash doesn't match anymore. It's happening more after the migration to NIP-96. 🤔


On all posts or just randomly here and there?


Sure. Make it local then :)


This is basically a nostr-wide watch party isn't it?

https://image.nostr.build/9921582fad999eb7f9f64c67ff67ba66fa393a1bf166b3be8fa9d9144f78149e.jpg#m=image%2Fjpeg&dim=864x1920&blurhash=%5B56%40Z-%2521WNd%7DdM_5%7EW%3FnOIoR%25ozF.o%7D%3DOn%7E5%7CXT%5B%7Bnh5hX9%5D%3Fs8NZNGw%7ExGw5RiKJju%5E8s9ATS5&x=de02b14db8604d7f69351d90bc3a0f220f4850a019f9105036416e8ee3729990


No, it means that those relays sent 4 separate messages that had 5 or more full copies of themselves in the same connection. They are helping to spread spams.


Disagree. The new one is definatelly better than signal, on par with SimpleX and worse than MLS for large groups. Signal is a centralized metadata-leaking mess.


Super cool!


OpenSats is like: Remember the "Other Stuff"? Yeah... we are on it.

https://opensats.org/blog/nostr-grants-december-2023


I am not so sure. You could buy influence from bigger accounts, but you couldnt just create random accounts to game the system.

Its similar to PageRank in that sense. Can you game it? Only because Google has all these other ways of looking at a page. But it is still the best we have.


Also, GiftWraps come from a random key. So, there will be a new conversation key for every wrap. The shared key only works in the internal Seals.


Sharing a conversation key does not allow anyone to forge messages. Just decrypt.


expected relations -> expected reactions.


We should have an Elo for Nostr Users just like Chess.

Every post can increase or decrease your Elo based on the difference between actual reactions to expected relations all weighted by the Elo's of the reaction authors themselves.

Maybe a DVM can keep Elo labeling people using NIP-32.


Views in the day. But I will probably remove it soon as it's becoming less and less interesting. Maybe a Bookmark button makes more sense.


It's ok. NIP-94 is too general for them. And they want to replace the video without replacing the reference for it. They might end up reusing NIP-94 inside the new kind, who knows..


hum... What's EPCM?


Probably integrate directly in the Reels feed as well.


What's not working? Flare seems to work great here.


Nice!


I keep saying: Everything will flow through Nostr.

Here's a YouTube competitor: https://www.flare.pub

And here's the NIP for it: https://github.com/nostr-protocol/nips/pull/923


Testing flare :)


fucking emojis. It's impossible to know if they are going to be rendered as one or two things. :(


Is this about the url not ending with .jpg?


Awesome, bring it on! let's see if it works :)


This is the new DM I am working on: https://github.com/nostr-protocol/nips/pull/686 and it is available on Amethyst right now. It tries to be as private as possible without having to have an AUTHed relay. I would argue that in extreme privacy implementations it could be more private than SimpleX. A client can have a DVM to connect to receiving relays for users and not leak your device's IP that would allow for some correlation even if everything is encrypted.

nostr:nprofile1qqsrmpp2lmx4u2fl9zmxy7fnwp9rlwxwz5a2j8tep2c376n494z2gtgpzamhxue69uhkjmnzdauzumn0wd68ytnhd9hx2tcprpmhxue69uhkxetvd3shytnwdaehgu3wwa5kuef0qyghwumn8ghj7mn0wd68ytnhd9hx2tcwamxyd  has a very good start with inbox.nostr.wine. The way to see the relay is as a mail box for the user. The user is paying for the relay to receive and store any event that `p`-tags the user. They might be spam or real messages. It's not the relay's job to decide which is which. It's the user's job (via a good client that helps you manage your inbox) to delete things that are spam and clean up their account with the relay from time to time.


> Just better encryption that does not increase the chance of nsec leakage?

Correct. NIP-44 is not a new DM NIP (that will be another number). NIP-44 just defines a better encryption scheme that any other NIP (including a DM NIP) can use. The offered protections by NIP-44 are against the needs of that individual encryption and not against the needs of a new DM system :)

In other words, you can definitely use NIP-44 in a way that is not private at all. The encrypted parts will be private, but all the other markers in the event can give everything away. It's like citing somebody in a NIP-04 message and adding a p-tag to that person outside the encrypted component.


Agree. What I wrote is explicitly about testing the pubkey of the event against the allow list. The pubkey is the signer and that should not happen. The p-tag can be used like you guys do to run the allow list. That's fine. You don't even need auth in those cases.

My answer to nostr:nprofile1qqs0kymx4027fjf2322s0yduwt23hh3fr2p42h9jcc56jtld67qx3tqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3jamnwvaz7tmvd9nksarwd9hxwun9d3shjtnrdakj7qgmwaehxw309aex2mrp0yhxummnw3exjcmgv4ejummjvuhsa6kd6c   was explicitly about the use of the pubkey and mixing signing and auth roles in one key.


Login with Nostr? :)


We should migrate them to NIP-44... in time. The overuse of NIP-04 does make the private key less safe. The more it stays out there, the worse it gets for users.


> Clients had to generate an alternate key pair to encrypt the message, so it looked like the message was posted by some random npub.

This is the correct way to implement private messages. The relay should not use the pubkey in the signed message to test against an allow list. Private relays CAN use an NIP-42 AUTH method to authenticate the connecting user (and not the signing user) and make the allow list about the connecting user. The signed message itself must hide the real user as much as possible because it can be easily broadcasted outside of this relay.

Needless to say that private relays that authenticate the user can track everything about the user and thus, by definition, are not very strong in privacy.


I am not sure what one has to do with the other. What the sentence is trying to say is that the the encryption scheme doesn't not need to solve the key distribution problem.


Or just use the new DM system in Nostr, which uses this new encryption. :)

What the NIP says is that the encryption on itself is not alone a good chat spec. But people can build really good ones on top of it.


Not by itself, but there are several proposals to implement basic chats and group chats with it.


NIP44, the new audited encryption procedure by nostr:npub10jcnehsxwrjepupvh602pl83up0dh3wv3fqfwv062smygqvpeuwsk03kag to fully replace NIP-04 has been merged!

The NIP04 is now officially dead.

GM.

https://github.com/nostr-protocol/nips/blob/master/44.md


It use use under 2GB of storage. Is it using more than that on your phone?


It's just like FB marketplace, you have to msg the seller to make the payment. But it could be a zap, a lightning invoice or a cashu token in the DM :)


Not yet


Why are you writting a json parser? Are the options out there not good enough?


Click and hold to change the amounts and then just keep one in the list.


Let's hope that service also returns content type. :)


Imagine when you get one of these bad boys: https://m.media-amazon.com/images/W/MEDIAX_792452-T2/images/I/71wPWGDeDIL._AC_UF894,1000_QL80_.jpg


It's the best thing ever!


Wait, you guys keep phones in your pocket?


We created one-tap zaps with Alby :). We released in march or so.


Sorry :(

Do you guys get opengraph tags for all links? If true, then you can check the content-type of the link when you ping the server. That's my fallback for when image urls don't have extensions, which will get more common as we evolve.


Aren't pagers just push notifications? :)


I think we order by follows right now, so that shouldn't happen. But i will have to check if it is true.


Just did, I think it worked!


I am trying to see if this is a bug or an issue in the server. Is it always nostr.build?


Yep. It should work just fine.


Well, just storing the nsec securely. If you need it, you can go to your friend's house and get the USB stick to recover the account.


The usecase is to give a device with your keys to a friend to store for you. This is a safe guard in case your house burns down. I think LOTs of people would use it if they had an easy way to safeguard their personal information.


I will just be using fingerprint-based USB drives for now. :(


Its unrelated to long-form. The red sign shows when the image server has changed the image AFTER the author has approved when writting.

Meaning that they might have cropped, might have inserted an #ad or might have completely changed its meaning.

It should be fine if you trust the server is going a good job, but that should not happen.


Not if it failed to load. I still need to improve that part :(


Are you in the latest version? 82.3?

It should only fail when the server doesn't reply in time. Nostr.build has been quite slow these days.


It's a keyboard bug. We can't do anything in the app :(. Try another keyboard, like AnySoft.


Interesting. Right now the list is fixed, but custom entries are coming up.


Anyone that writes a 3+ paragraph message in a single chat message is likely a bot :)


What do you mean? Any errors I should take a look?


They post the same stuff so much that dilutes any chance of being effective.


It's ok, but frankly it's just spam at this point. No one even reads them.


I could upload through Tor, so that def no it. 401 is unauthorized. I am wondering if there are any protections they added. I will keep checking :(


Unread records are unique to each client. There is no standard yet to be shared between apps.


I wonder if they are blocking Tor. Let me check.


Very strange. Is the image too big? I just tested and they seem to be receiving just fine. Are you using Tor?


probably


Interesting, same error on all servers?


Does it show any error?


Sure, a spec is a spec. But the same spec also allow any other reaction, which I prefer to focus at. In that way, those debating if + should be a like or an upvote can sort themselves out without our interference.


The two should have never been the same encode. They are not the same reaction. Clients do not use them in the same way. Semantics are all different.

It's just wrong.


Like I said in our call, every NIP is wrong. :)

I have had long discussions about this +/- encoding and I concluded that it is better to not interfere with UP/Down vote clients.

Otherwise, the weight of Amethyst in their stats breaks everything.


Neither does NIP-94/95, but here we are :)

But imeta or not, this idea of checking if a link is an image or not by checking if it ends with .jpg, ignoring all query params and fragments, is never going to work.


Probably they just need to adjust their algo to remove # fragments before trying to identify if the link is an image or not.

But the real way to solve this is to ping the server to download the opengraph preview and checking the content type before downloading the image.


Just keep in mind the + is not a like. Many other clients use it as an UP Vote ⬆. Adding an up vote without also adding the DOWN vote might break their stats. that's why we are not using it anymore.


No idea. Why not? They are just regular image links.


GM. My dream when start building Lume is it can use as a Nostr Relay, and today I near achieve it, this feature is almost ready, I will show it to you guys in the next week 🔥

https://m.primal.net/HTyb.jpg


I have not tested self certificates, but it could work in native (user can choose to trust). I am not sure about web clients, though.


In time, yes. It is going to take some effort to create a good hardware for Nostr.


Yes, you can use IP directly. I am not sure about the CA cert, but you can definitely do CA on the IP level and not in the domain level.

But my main point is that clients need to find events. And the way we do it today is based on fixed relay sets. Nip65 allows people to migrate from relay to relay AND tell everyone following them where all the events can be found, similar to an update in the DNS registry to a new IP.


Did you update? It should detect unless the server is offline


Actually it might be something with nostr.build. it's very slow right now.


Gotta update. :)


Large private and public groups as communities. nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9rhwden5te0wfjkcctev93xcefwdaexwtcpzdmhxue69uhk7enxvd5xz6tw9ec82c303dhy7r  is pushing something huge. Can't wait to support this as well.

https://v.nostr.build/maAK.mp4


NIP-65 is basically a DNS resolver for Nostr.

Like DNS, you can move your data from one IP to another and just use NIP-65 to point to the new IP address.

People won't find your posts if you don't set your NIP-65 address correctly.

PS: Not all clients can do this yet. Amethyst can't. But it's the future.


Isn't this just another layer? :)


Yep, that is a view count of the post. The count is in memory only and resets every day. So, its more of a how many people have seen it in the last 24 hours than anything else.


Me: No one is going to go through the trouble of individually adding more than 10 emojis to their list.
Users:

nostr:nevent1qqsr27lz73emylwmpy77q3uzxjdsyflpvwwaqu06vpk78zf0ddwxh6cpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcprfmhxue69uhkummnw3ezuurvv43xx6rpd9hzummjvuhszythwden5te0xy6rqtnxxaazu6t09uq35amnwvaz7tmwdaehgu3ww35x2umpd4jkxct59e5k7tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3jamnwvaz7tmjv4kxz7fwdehhxarj9e3k7mfwv96j7qgmwaehxw309aex2mrp0yhx7unpdenk2urfd3kzuer9wchsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qg3waehxw309ahx7um5wgh8w6twv5hshh0n97


Too much trust on the server operator. It's better than anything else but there is still too much trust. https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md


You are always breaking my stuff.

Keep going.


Well, it has been 30 minutes since I posted so I bet nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75sprpmhxue69uhhyetvv9ujucm4wfex2mn59en8j6f0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z79z4kue  has built it already.


Also Clients can suddently send the same message through several routes and the receiving relay will automatically remove the duplicates.


I just realized it will be better if hops were regular events with expiration dates instead of full-on ephemeral. So if a DVM gets offline for a few seconds, there wouldn't be a delivery problem.


Probably, but each DVM would be so freaking simple that a snowflake proxy is probably way more complicated than it.


Yes, you can join. But will you stay? Majority of the Nostr users play with it for a few days and then walk away. They have to find that peer to welcome them. Otherwise, it doesn't really work.


I thought ark was the only non-custodial "ecash" solution, but if we can do non-custodial e-cash, zaps over that do make a lot of sense.


Nice! So, we just need to updated it to be a DVM and the new encryption scheme.

Maybe we can add a cashu token in each hop to pay for those services? nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0dehhxarj9ehx7mmwv4ejucm0d5hsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshs26ym66  , if I encrypt a cashu token from the same mint in each hop, can each server use that info to identify who am I?


Can we build a Nostr-native onion routing for private events using DVMs?

Each onion hop is a GiftWrap using an Ephemeral event kind encrypted to the next onion DVM. The client assembles all hops and sends the private message to the first DVM via the user's main relay. That DVM decrypts the ephemeral event and sends it to the next DVM. The last DVM will send it to the user.

This minimizes the user's IP leakage to the set of trusted relays that user likes while sustaining the relay decentralization properties of NIP-65.

User's would never connect directly to the read relays of other users because they might not be trusted.

Since the relay knows your Nostr filters, it does know which pubkeys you are interested in (including your own key). Decoupling sending an event to a pubkey and filtering events for your pubkey in the same connection/IP is key to reducing the power that the relay has over you.

This would be akin to using several Tor sessions, a new session for every new message you send, while giving the Client the power to choose different "exit" nodes (DVMs) at each new message.

Am I crazy or is this actually better?


> ‘Cannot: see who sends messages to the user and who the user sends the messages to’.

That is just for any other user in the network. In practice, Alice will share a receiving queue and a server with Bob. Alice then will connect to that server to download her messages. Bob will connect with the same server to send a message. At that time, the server knows the two IPs that are using the same queue and can start mapping people talking to one another, the more they reuse servers and IPs with different conversations, the worse it gets.

One of the designs we explored for DMs in Nostr is to use multiple relays and our broadcasting capabilities to send and receive your messages with rotating pubkeys (akin to queues) for the same user (but not for each conversation) in a way that it reduces the correlation factor / the power of a single receiving server. A Nostr-native onion routing for events, if you wish. The server should not be able to identify when the same two people are talking to one another.

Also, the network should not choose the server for you. That can lead to additional enforcement options by the court.


You have to trust the SimpleX server operator you are using: servers can track you if they decide (or are compelled by the court) to do so. They documented it here: https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md


Super easy. We can use something like:

```
{
  "kind": 30382, // Relationship Status kind
  "tags": [
    ["d", "91cf9..4e5ca"] // contact's pubkey
  ],
  "content": "<NIP-44 encrypted Stringified TAG-List([
    ["nickname", "Big Joe"],
	["status", "<Known Face, Contact, Following, Coworker, Friend, Partner, Family, Extended family, Trusted, Competitor, Traitor, Used to Know, Scammer, NSFW, Unkown, etc>"],
    ["summary", "<summary of the relationship>"],
    ["email", "bla@ble.com"]
  ])>",
  // ...other fields
}
```


Brave with Nostr accounts for Sync and Zap/LN for transactions.


It's not easy :(.

Maybe Block would be a better buyer for Brave. Strike would be a close second.

Just saying, nostr:nprofile1qqsgydql3q4ka27d9wnlrmus4tvkrnc8ftc4h8h5fgyln54gl0a7dgspz9mhxue69uhnzdps9enrw73wd9hj7qgnwaehxw309ac82unsd3jhqct89ejhxtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsa887h4  and nostr:nprofile1qqsvf646uxlreajhhsv9tms9u6w7nuzeedaqty38z69cpwyhv89ufcqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq35amnwvaz7tmsw4exzanfv3sjumn0wd68ytnvv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs8d5ukj  ... Every one loves Brave. The only thing people hate are BATs.


They should buy Brave out and replace BATs with BTC.


Looking forward to your solution. We have been working on a new DM scheme for over 9 months. What I can say is that we went through a bunch of ideas and they all felt short of their initial expectations. In my mind, even new things like SimpleX is not good enough. We must find a way to do better.


Are we going to have Zaps with Ark? :)


Agree, it doesn't need to be focused. But the focus really helps. I would love to see a What's App alternative.

And agreed as well: push is key. Frankly, every client should have a great push notification support, even if it is a centralizing move into their servers.


Yep, nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9rhwden5te0wfjkcctev93xcefwdaexwtcpzdmhxue69uhk7enxvd5xz6tw9ec82c303dhy7r  applied for the new NIP-24 GiftWrapped DMs with small groups that several clients are implementing. At the time, I told them to not award anything until we get sufficient support from clients and a cryptographic verification on nostr:nprofile1qqs8evfumcr8pevs7qkta84qlnc7qhkmchxg5syhx8a9gdjyqxqu78gprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmp9ehx7uewd3hkctcsz6alh 's new encryption scheme. The audit is being finished right now, so we are going in the right direction :)


Yep, Amethyst's push notifications are GiftWrapped (DMs are triple wrapped), dates are random, and the receiver's pubkey is removed. There is no way for the push network operator to know anything about it.  All they know is your device token.

Sure, they might face regulatory pressure to KYC device tokens, but at that point you can just set up your own Notification server.


Before you ask why a Chat client grows faster, it's simple:

The onboarding experience is almost friction-free.

There are no random dick picks in new people's DMs. There is no need to find interesting people to follow before making things usable. You don't even need to think about what's interesting to you. There is no need to setup Zaps and there is no need for NIP-05. They are not even going to find political takes they don't like just to be angry about in the first 5 minutes of using the app.

Most of the time, new users don't have anything to say publicly. But there is always something to be said in private. That is how you get them going.

If DM clients really want to make things complicated, they should guide the user into choosing a DM relay, like inbox.nostr.wine. But the rest is just install and message your friend. It couldn't be simpler.

Sure, this only works because the other Nostr apps keep the social structure active. If you were to release a whole new protocol just for chats (outside of Nostr), you would face tremendous resistance. But here the Nostr network effects will work in your favor.


Take it from a Twitter-clone developer: Chat-only clients can reach 10x more people and grow faster than any Twitter-like client will ever do.

nostr:nevent1qqs0l3etkyf3wqyjltk2zdx8es403p67hvr787ac720f3pz0t6s5l3gpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprpmhxue69uhkummnw3ezuendwsh8w6t69e3xj730qy88wumn8ghj7mn0wvhxcmmv9uq3samnwvaz7tmjv4kxz7fwvd6hyun9de6zuenedyhszyrhwden5te0wdhkcmmrduhxump0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hszyrhwden5te0vyhxummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshszyjsq9


If this is because your infra can't scale fast enough to support the new users coming in: Congrats! Thats an awesome achievement and a great problem to have.

If this is because you are afraid of losing people's funds: We hear you. Thanks for letting us know and force the issue before it happens.

If this is to prepare for a business model where alby is a paid Wallet, this is a great way to go.

If this is just a marketing play to create a false sense of exclusivity, it's not going to work.


I would argue that it is exactly what should happen. Quotes should not be used like that. Of course, authors can choose to do so, but it's their audience that will suffer.


Yep, that's the goal :)


Yep, the global search will be based on the screen soon.


Install via Obtainium. FDroid will always take 2-3 days to approve it. It is an unfortunate reality of a centralized repository with no paid person to approve things quickly.


How much trust is actually there?


Tem vários por aqui


What happens when we have more than 1M sats in the account already? will it stop receiving?


No, did you install the Play version? The translations are not available on the FDroid version.


But the long-term goal for reels is to have media that "works" independently from any text to give it context.


It's a NIP94 feed of media files. We keep it separate from the main feed because they might be used as an attachment inside a regular note. If you display both, then it would appear duplicates in the main feed.


There are so many ideas for versioned events. Somebody just needs to create a crappy little prototype for these things.


That's what block does. It hides everything from the person.


It should be there already


#Amethyst v0.82.3: Performance improvements

This version has a 10% reduction in temporary memory use when scrolling (garbage collection was being called all the time).

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


And we don't even have real automated tools to help assemble lists by topic, locations, relationship status, etc. :)  That's when things get exciting.


Actually the app does have a good cache these days and will only redownload if you kill the app from memory (swiping up in the apps view).

We are finishing a local database to keep many objects local but that will only help in these re-starts.

In the end, Amethyst is a huge app and will always do a lot. You might want to find an app that only has the features you want. For instance, you don't want the app to show any counters of replies, zaps, likes, etc as you scroll. Or if they do, it's just a rough number, instead of an accurate one.

You can always select to not load profile pictures (each profile picture can be 10MB alone) and other images/videos on the app settings. That should reduce the amount of data used. You can also use the FDroid version, since it doesn't download any translation model (~30MB each).


I can help if somebody wants to refactor the code and take the lead on the iOS version, but I will not do it myself.

Here's why:
1. There are many good clients for iOS already. None of them is as good as Amethyst, but they don't need us.
2. Spending my time on iOS will take time away from Android, which my users will absolutely hate. It's akin to treason.
3. I believe iOS is incompatible with the decentralization goals of Nostr and people that trully care about decentralization should move away from it.
4. Vertical integration in the Android stack is what will make Amethyst a better app. The deeper we go, the better it gets. You can't go very deep when you abstract the operating system/hardware away. Besides, we are native. Web apps are better suited for a horizontal deployment.
5. If we trully want decentralization, it doesn't make much sense for a single project to try to take over in all platforms. Let other people focus on those platforms.

Anyway, My main goal is to create the best Nostr experience on an Android. Any time spent outside this goal is a distraction.


#Amethyst v0.82.2: Markdown improvements

The last version created some issues for the preview of images and videos in Markdown content. This should fix all of them.

- Fixes the transition between short preview and full text on markdown
- Adds NIP-44 metatags to markdown rendering.
- Adds background video rendering on markdown
- Performance: Calculates the text width of a space outside a composable.
- Fixes the image preview with uppercase extensions.

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


Good evening!


Testing


Most people still have them on Kind 3s. But the new model is NIP-65. I would sent to all write-enabled relays in both lists.


Order or listing? Third button in the new post page :)


oh so it's not that you can see replies in another client but not on Amethyst. Understood.

Yes, that seems to be that the app was offline in the moment you sent. :(


Hum.. it could be. Shopstr only uses a few relays. 🤔. I will investigate.


Are you paying for Nostr.wine? If not, remove it from your relay lists.


Yep, a simple screenshot. That would be great.


How would you improve Amethyst UI?


Nice! Let's go! 🤝


Nice! Every web client should do this :)


Any specific example?


Not missing anything 50 is what is there


Yep, the video won't float as you have with YouTube, but there will be a notification that the video is playing.


It seems valid now. Am I missing something?


It should keep the position of the last 10 videos in memory. Does it work for you? Should I increase that number?


I am going to change my title to Sentinel of Nostrish Fallibility.


What's the bug with npub@cashu? I don't think I have seen it anywhere :(


Click on the top-right button at the corner of the video to send the video to the background.


Sure thing! Profiles are becoming too big, so we might need to remove a few things to add this :)


#Amethyst v0.82.1: Marketplace, NIP-96 Image Servers, NIP-54 inline metadata

Adds support for selling and listing in Amethyst as well as NIP-96 Image Servers and NIP-54 inline metadata. Provides large improvemetns to Cashu's token redemption and fixes several bugs.

https://image.nostr.build/40ae418ccc5336e17b5949bacc11c31835603437816f8bf867c171f07d34dd54.jpg#m=image%2Fjpeg&dim=720x1612&blurhash=%5BLFFgJMyj%5Bt74TMyoft70LxufiV%5B_Nt7f6WB4TogoMj%5Bxut7ofWAS%7EofbFjtD%25xtWBWBs%2BM%7BjbbH&x=c3a3f49c017f58749226f8ae6021c11a745d2354f52a229cb99eef4a9d20ec39

- Adds selling: ShopStr's classified creation
- Migrates old image server uploads to NIP-96
- Adds support for NIP-54 inline metadata
- Adds a Marketplace tab to Discovery
- New Cashu Redeeming card UI.
- Shows the blurhash with a Download icon instead of the URL when the user chooses to not automatically load images/videos
- Improves the video switching flicker from blurhash to video
- Optimizes the rendering of the drawer
- Updates EOSE status in the same thread of the new event to reduce the amount of coroutine launches.
- Uses just one HTTPClient for the entire app
- Adds a User Agent to all HTTP requests.
- Improves Cashu Redeeming UI feedback
- Adds support for the FileServers kind
- Adds relay information for Replaceable events
- Unifies upload options into NIP-94 images
- Improves the rendering of inline metadata
- Uses nostr.wine instead of filter.nostr.wine as a search relay
- Fixes bottom bar appearing in chats when the keyboard is open
- Fixes uploading crash due to malformed video formats
- Fixes crash when image is an SVG and tries to compress
- Fixes deletion of replaceable events
- Fixes hash calculation from the entire payload to only the bytes in the file
- Fixes bug when updating relay list that used keep the previous list
- Presents better error messages when the image upload fails
- Adds a button to Cashu preview to redeem on external wallet by nostr:npub1nxa4tywfz9nqp7z9zp7nr7d4nchhclsf58lcqt5y782rmf2hefjquaa6q8
- Fixes zap splits when using amber with intents by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- Updates translations for cs/de/sv/pt by nostr:npub1e2yuky03caw4ke3zy68lg0fz3r4gkt94hx4fjmlelacyljgyk79svn3eef
- Updates Hungarian translations by nostr:npub1ww8kjxz2akn82qptdpl7glywnchhkx3x04hez3d3rye397turrhssenvtp
- Updates Finnish translations by @petrikaj
- Updates Dutch translations by nostr:npub1w4la29u3zv09r6crx5u8yxax0ffxgekzdm2egzjkjckef7xc83fs0ftxcd
- Updates French translations by nostr:npub106efcyntxc5qwl3w8krrhyt626m59ya2nk9f40px5s968u5xdwhsjsr8fz
- Updates dependencies

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


DONATIONS TO OPENSATS ARE TAX DEDUCTIBLE.

IF YOU HAVE A LARGE TAX BILL THIS YEAR CONSIDER SUPPORTING FREEDOM TECH 🫡

https://opensats.org/


ohh, there is no space between the emoji and the https:// in the original message. So it looks like the schema for the URL is "🫡https://"


It doesn't open on Coracle as well.


I use it a lot for screen generation. Like this: https://chat.openai.com/share/c8a39151-5f50-4945-a928-cbb373adf66a

Things I can quickly review are simply awesome.


The ZapChef Network is growing.


This is very interesting. I still think a good code review AI could be a game changer.

https://image.nostr.build/cbec69114e93d8fcf3c335cb742873f8e97dc09a2aad79b8dd5adfa589d0bc51.png


Which means I need to start using less memory. Android is killing the activity and restarting the feed.


Thank you! Do you see it restarting the screen, like when it shows "Loading Account", or just blinking to the top?


2023:
- 77% of developers use ChatGPT.
- 46% of developers use GitHub Copilot.

GM.


When does it happen for you? When coming back to the app after some time or during screen transitions?


I just gave nostr:npub17meshv2lg6rfyuwzgh349yslllq7aathd55xu0jgjns2ayz6rt2seplm8u the calendar I bought her from nostr:npub17nd4yu9anyd3004pumgrtazaacujjxwzj36thtqsxskjy0r5urgqf6950x and she absolutely loves it.

Thank you! 🙏🎨 #artstr https://i.nostr.build/LWJ6.jpg  nostr:note12wwrsaznp4glqmh8wm2eaqj4y7t2juadhcr2zd0ux240zd7zsa7qj3cvmt


Yep, that has been addressed. There is a key alias design that you can rotate pubkeys to receive DMs. I dont think anyone has coded that yet and it might not be needed since people cant even see the date/time of the message. It could be old, random noise


"Apple dont dare to do this"

lol. Apple has been doing this since the iPhone with huge sucess and their users don't even notice.

Also, there is no need for hardware monopoly. Just look at TikTok, Twitter, Facebook, Twitch, Substack. Mind-share control is the oldest trick of big tech.


We had a bug on saving relays in this version. Bug fix is coming soon.


Same share of the number of people that store gold bars at home.


> The status of creators and content consumers is equal, and no one needs to ask anyone.

Sure, but that's not the point. My point is that if the Client is incentivized get consumers to spend, the Client takes the creator's side. And Creator + Client together will smartly play the consumer so much that it will be equivalent to the weak patient description in the medical case. Consumers won't even notice. In the end, consumers will have to choose a Consumer-first to even fight the attention-seeking drainage of zap-share apps.


Sure, language matters, but the language choice is nowhere near the top of problems we face today. If that is the battle you want to fight, go for it, but there are more important deficiencies than the choice of language IMO. Go is fine.

By more important deficiencies, I mean:
- monolithic servers will never scale to the amount we need.
- overall lack of libraries to quickly put together a brand new relays.
- current load-balancing, indexing and caching systems are terrible
- relay maintenance/monitoring tools for devops are non-existant.
- user tools for personal servers are also non-existant.
- performance is quite poor for the amount of resources being used.
- huge architectural mismatch between modern warehouse infrastructure and the codebase

Anyway, there is a lot of work.


Audits of the new NIP-44 encryption for DMs are up: "The fact that Cure53 was not able to identify any exploitable vulnerabilities can be
interpreted as a positive sign in regard to the security of the NIP44 specification and
implementations. "

But they did offer suggestions to harden the security that will be implemented soon and warned against naive implementations of secp256k1. 🚀

For those who want to read more: https://cure53.de/audit-report_nip44-implementations.pdf


Nice! Thank you!


It's hard to believe it's impossible. Maybe Core should start breaking the main repo down into libraries to allow some interface specification of the consensus part? Sure, It will need additional financial support to break it down, but once done,  making things compatible can be assured simply by comprehensive coverage of test cases. And once the main interface is covered, new implementations can start to flourish.


How should one measure the level of compatibility of other Bitcoin implementations?

We all love Bitcoin Core, but I really wished we had 20-50 other fully independent but also fully compatible implementations.


Yep, but that was just the demo :)


Google Gemini Voice will teach English faster and better than Duolingo. You can just discuss facts of the day, or any topic you like, with an agreeable AI in a second language. And the AI will answer any grammar or vocabulary question in the middle of it.


It has to be a user in the new zap-split design :(

Maybe create a pubkey for them and add their wallets? 🤔


Follow lists are coming to Gossip! Let's go!

nostr:nevent1qqsq4v6uqf55e8jkq377jvrd2mhdtynx3jvz2a8kjf7yej3t2mgd0hcpzpmhxue69uhkummnw3ezuamfdejsyg8wzxjalaqvrxj4taqlus453uqwvxxfzgjky2hr0dkzhdnmwmzwfypsgqqqqqqsqkhk0l


Where is the zap split to your kids accounts? :)


The language of the server is irrelevant.

I am more concerned with the lack of competition in the relay dev space. We don't want to end up in the same state as Bitcoin core that only one codebase is relevant.

Let me know if you need help brainstorming ways to fundraise. I can hop into a call if you need.


Yeah, the state of relay development is terrible right now.


A single client doesnt need to solve for both.

People can create in a separate client. Client A will take care of consumers, Client B will take care of creators.

Each client will solve their own part of the problem much, much better than any client trying to solve for both at the same time.


I don't even think you need a base subscription. It is a harder model to make things work, especially because it is not that common anymore, but it is worth a try.