2024-05-16 18:03:00
- reply
by npub1gcx…nj5z
The Play edition uses firebase, the FDroid edition uses UnifiedPush with your server of preference. The notifications themselves are giftwrapped, so neither Google, nor your UnifiedPush server can see anything, not even your public key.
VPN + Tor, just hides the traffic from your ISP. To relays and others, the Tor exit node is still the same for both accounts. So they can reasonably see which accounts go together if they track you over time.
If apps have Tor internally, they can choose different Tor sessions per account and even per nostrs filter. It's a lot of work to make it work, but possible.
2024-05-16 09:09:58
- reply
by npub1gcx…nj5z
Yep, our push server knows which keys are in which device ids if you activated Push Notifications. But that into is not public, only the push server sees it. Device IDs are random numbers, so they don't expose any other info about you.
But if you are concerned about that, you should know that if you use multiple keys in the same device, relays and image servers, including proxies, can also see which keys are together by just logging where requests are coming from. They can do that roughly well even through Tor.
VPNs can muddle this info, but the VPN server itself will also know that info (and much more).
Happy to code schemes that obfuscate that info, but to the best of my knowledge, Signal, SimpleX servers also know the same info based on Device IDs/IP info.
2024-05-10 22:38:37
- reply
by npub1gcx…nj5z
Yeah, but chain operations become extremely expensive over time.
> If all I have is a pubkey, how do I find the corresponding IP?
There are many ways, but you basically would have a boostrap IP that can download NIP-65-like events of other relays. We could even use WoT to ask your friend's client to become the Bootstrap relay. Once you have a list of available options saved locally, you can easily get updated records by just querying a few of them. And if they go offline, you update the list with new ones. As long as you know the IP of a single relay, you can get all the others.
2024-05-10 18:58:13
- reply
by npub1gcx…nj5z
The incoming order in multi-filter subs also varies a lot. Some relays send all matching events for the first filter before starting the second. Others do all at the same time. Others break them in chuncks. So the order of arrival cannot be relied on.
You can save the last EOSE, but you will need to update it when live events show up in the same subscription after the EOSE is received.
However, events in the past show up all the time. I initially thought this was a problem for GiftWraps alone, but no. Every event kind has this problem. Because `since` is based on the `created_at` and not in the relay's receiving date, when using `since`/`until` you are bound to miss events were broadcasted late, like 1hr or 1 day later. This is particularly problematic when users are not using large relays. Their messages might arrive later just because somebody else replied there and re-broadcasted the original not to the rest of the relays.
Either way, EOSE/since/until will be broken until something like negentropy or https://github.com/nostr-protocol/nips/pull/826 becomes widespread.
2024-05-10 14:05:10
- reply
by npub1gcx…nj5z
What bothers you about it?
For instance, some people don't want the encrypted events being sent to a relay, so we are coding a relay setting for a local database of drafts (and other settings). In that way, you can use something like Citrine to store your drafts and avoid putting them out in your regular relays.
So many people have lost what they were typing on Amethyst that Drafts became our solution to make sure that never happens again, even if the app has a bug and crashes, the Draft will be saved.
2024-05-09 20:31:08
- reply
by npub1gcx…nj5z
Your first comment was about last word being a "bad idea" to you and that "Post + mute thread seems more healthy to me." Being more healthy or a good or bad ideas don't necessarily touch ethics.
My reply was about refraiming from determining "what's good for the user", which also doesn't necessarily involve ethics.
We don't know the user. We think we do. But in reality we don't. So, to me devs debating what is a good or bad idea "for the user" is silly. We can talk about good and bad implementation paths, but ideas are so much more than that.
In other words, using hex for heys was a bad idea, but it doesn't spur any ethical concerns. Lastword to me doesn't touch, change or impact ANY ethical position we might or might not have. It's literally just a way to encode a "mute thread".
2024-05-02 17:11:09
- reply
by npub1gcx…nj5z
Tech can't protect itself against government. We can make it more difficult, like with mixers, end to end encryption etc, but in the end, laws and regulations will always trump it. Whatever tech stack plugin we create to protect bitcoiners can just be declared illegal by government.
That doesn't mean we should give up an not try to protect, but we need to be conscious that we need strong, constant political pressure to actually solve it.
2024-05-02 16:39:31
- reply
by npub1gcx…nj5z
I wouldn't call sheepish. People have too much to do on a daily basis. So, to simplify they attach themselves to brands until the brand doesn't work anymore: eg: "I don't know how to keep my bitcoin safe, I will just use Coinbase for now", "I don't know how to make a phone, I will just use Apple's for now", "I don't know how to plant onions, I will just use the market's for now", etc.
It's not being sheep. It's practicality. But that practicality is also what rug pulls them all the time. For many, these brand rug pulls are just anticipated as "cost of living" (akin to the "cost of doing business").
2024-05-02 15:36:37
- reply
by npub1gcx…nj5z
The DID anchors all signed packages by the key defined inside of it. But the DID doesn't create "Trust". Spammers can have DIDs that anchor all of their messages that you can verify. But the "Trust" only comes when you verify the did (or a VC, like you said) from an entity that you already Trust.
A Trust "Anchor" is then the master entity whose all trust derives from. Sure, you can have many Trust Anchors, but the Orange Check is specifically marked as Microstrategy's anchor keys.
There is no way to have only one Orange Check for multiple Trust Anchors, since their trust-verifying methods can be completely different from one another. And if they are all the same, then it is almost as if there are all derived from an invisible Trust Anchor. A Trust Cartel if you want.
2024-05-02 14:54:37
by npub1gcx…nj5z
Microstrategy's Orange Decentralized Identity (DID:BTC) project is basically DID:ION, but it stores changes to the DID Document JSON as an OP_RETURN in the blockchain itself instead of on IPFS.
There is a coding scheme to declare changes to existing JSONs and store them as new spend transactions. The DID:BTC:<address> references the creation event. To reassemble the complete document, follow all spends and apply each change to the DID Document as specified.
It's cool that it is decentralized, but this is like Ordinals. The use of the chain for every change can be quite data-heavy.
The funniest thing is Microstrategy demonstrating the use of DIDs to sign regular e-mails. Once you use DIDs to sign/verify, you can use any other DID method, including DID:NOSTR or DID:MYCOMPANY. They are all equally "decentralized". :)
What Saylor clearly doesn't understand is that DIDs are already decentralized by definition. Adding a blockchain method doesn't make it more decentralized. The user's choice of method is the decentralization feature (like choosing which relays you want to use).
2024-04-29 22:42:23
- reply
by npub1gcx…nj5z
Client asks 1 hash for everything, if it is the same, stop.
Client asks for 1 hash per week, pick the week with missing events (likely the last one), ask for 2-day interval hashes.
You can start per month as well, dending on the system's confidence over it's up-to-date status.
Right now, I just re-download the past two days. There is not enough DMs to be a problem anyway.
2024-04-29 20:26:38
- reply
by npub1gcx…nj5z
I am not sure if it's possible (or desirable). Usually there are specific features (or simplifications) on each of them to warn a separate protocol.
For instance, if you are doing a private zap, you want the amount to be public and the rest private, which creates metadata leaks on purpose. Sometimes, "leaks" are desirable. In other times they must be forbidden.
But who knows, maybe there is a way to merge them all.
2024-04-27 16:42:43
by npub1gcx…nj5z
It's quite interesting to see how tech has completely changed the work of the common cop against the common thief/murderer/gang member in the last decade. Especially in developing countries.
Before smartphones, cops had to work disproportionately hard to assemble evidence against "simple" crimes. These days, all they need to do is to get the murderer's phone and the hard evidence they are looking for will reveal itself. Almost all common criminals use their phone to organize and manage their heists.
And, what's even more interesting: this is not a secret. Cops know low-level criminals do not have other means of organizing. So, even if everyone knows cops are looking at phones, criminals can't help themselves but use it.
2024-04-24 17:20:29
- reply
by npub1gcx…nj5z
1. Network effects are baked-in. Devs don't like to sell/advertise. It's nice when you can just create something and use an efficient social design to let word-of-mouth do its thing without relying on a controlling party, like an app store. It's also incredibly rewarding.
2. Database is solved. Users will choose their relays. You don't need to put anything up. There is no need to spend hours specing out your database tables, mapping them into objects, and then making all the data access layers. No liabilities, no operational costs, no risks, and, more importantly, no long-term commitment to secure and keep the data available to your users.
3. Login is solved. Devs generally start any app with the Account Management part, designing screens, o-auth backend, password recovery, 2-step auth and so on. It takes a lot of effort to get to the point where you can actually build the app you want to build.
4. Social First. Every app is a social app. But devs usually build things first and then add a social "feature" into it. That doesn't work. With Nostr, you are forced to start with the social component and build what you want to build on top of it. And devs see that as an extra positive feedback loop for the community.
5. Do whatever you want. It's shocking how open Nostr's data models are to any type of application. Just pick a number, sign, and go. Make a NIP if you want to interoperate with others.
2024-04-22 23:46:49
by npub1gcx…nj5z
Are you ready for this?
```
{
"kind": 35337,
"content": "",
"tags": [
[ "d", "SheetStr Demo" ],
[ "data", "Sheet1", "J", "25", "3"],
[ "data", "Sheet1", "J", "26", "5"],
[ "data", "Sheet1", "J", "27", "=SUM(J25:J26)"]
],
"created_at": 1713819120,
"pubkey": "...",
"id": "...",
"sig": "..."
}
```
2024-04-20 01:08:20
- reply
by npub1gcx…nj5z
What's the share of all reports by the bot that generated this reaction? Because of course no one is going to reply happy that the bot reported them. What you are seeing is self-selected to be argumentative... to the least. The vast majority of users won't care about your bot's notification.
I just loaded some of your bot's reports. All of the ones I see are related to language slurs. I don't think they should be reports. They should be content ratings in the kind 1985's label event, not reports of kind 1984. I don't understand why you are forcing the issue.
For instance, one of the reports happened simply because the user said "Sick fuck". That is a terrible way to behave online, but it's not a reportable thing. What are relays going to do about this? Delete everyone that used `fuck` in their posts? That will wipe most of Nostr out.
If you used labels, we can have content ratings to avoid showing these slurs when kids are using the app. But adults should be able to see them just fine.
Was this "Other" category created just to find a way to use labels in the 1984 event? If so, I am starting to think that was a mistake.
2024-04-17 18:17:30
- reply
by npub1gcx…nj5z
My understanding is that Double Ratchet requires a strict order of messages and it is quite unforgiving when one of the messages is deleted. Since that happens all the time on Nostr, because relays generally not have everything or sometimes are just offline/busy, it might not be a good usecase. Key derivation branches would happen all the time.
The algorithm works better when a single server takes some channel management responsibilities and maybe even keeps the state of the ratchet machine, which I don't think we can do in Nostr.
I know there are fixes for it, but I didn't explore them because it gets quite complicated.
Also, keep in mind that Double Ratchet is just a concept. There are lots of ways to implement it and each has distinct levels of privacy and security with many side effects.
2024-04-15 17:44:17
- reply
by npub1gcx…nj5z
Education is only useful in the first 10 years after school. Then it's not that important anymore. But it is a good predictor of what parts of the coding culture they care about, like building things from scratch vs reusing libraries, quick vs quality work, foundations vs hacking, science vs intuition, etc.
2024-04-11 18:26:00
- reply
by npub1gcx…nj5z
Also Oobiyou's note you screenshotted is only available on nostr.wine, relay.nostr.band, nproxy.kristapsk.lv, tmp-relay.cesc.trade, search.nos.today, ca.relayable.org, purplerelay.com, soloco.nl and some other less known ones. Looks like only Nostr.wine is on your list. Can you check if your phone is receiving notes from them on your relay list page?
2024-04-05 14:36:58
by npub1gcx…nj5z
Much has been said about Inbox/Outbox relays lately. Inbox is the relay you use to receve posts from others. Outbox is the relay you use to offer your own posts to others. Both of these are public, anyone can download events from them.
Lately we have been debating a third relay type: Private Inbox: An inbox that receives anything from others but only you can download them. It's great for private messages and other sensitive content.
Yesterday's release of Drafts is making me think there is a 4th type: Private Outbox. A relay to store posts of an author that only the author can download. It can be a local relay, like Citrine on Android, or a remote Authed one.
A Private Outbox relay can be great to save things no one else needs to know but are core to the user experiene of any app: Your app settings, drafts, which posts you have viewed, mute lists, private follows/bookmarks, etc.
One of the next steps for Draft Events is to make a setting to pick which relays to send your Drafts to. And because of the Auto-save, a local relay running on your Android can be the ideal place for them:
https://github.com/greenart7c3/Citrine
2024-04-04 23:20:06
by npub1gcx…nj5z
#Amethyst v0.86.0: Draft Support
This version adds support for draft notes autosaved on your relays, a new simplified UI choice on Settings, changes the Discover tab algorithm to show the latest of chats and communities and much more.
Features:
- Draft notes for feeds, replies, live streams, public chats, NIP-04 DMs, GiftWrap DMs, polls and classifieds by @npub1w4u…0jr5
- Adds autosave for Drafts by @npub1w4u…0jr5
- Adds edit draft in the dropdown menu and the long press popup by @npub1w4u…0jr5
- Adds a Draft feed screen for all posts
- Adds new algorithm to parse OpenGraph tags by @npub168g…2dlc
- Adds a Simplified UI setting to both feeds and chats
- Moves the username play button to the profile page.
- Adds link to the version notes when clicking in the version in the drawer
- Brings new git Issues and Patches to the Notification
- Filters out too many reposts of the same note when on the main feed
- Updates the bootstrap relay list
- Adds missing classes to support WebServer connections in the Video Playback
- Slightly reduces line height for improved readability
- Reduces the space between chat bubbles.
- Migrates shareable links from habla.news to njump.me
- Restructures the Discover Tab to show the Chats and Communities with the most recent new content.
- Adds a bot field to the user info
- Adds k-tag to the Deletion events
- Adds button to load Zap Splits from the cited users in the text
- Several accessibility improvements by @npub1e2y…3eef
Bug Fixes:
- Fixes the post cut-off when the post has massive string chars without spaces or new lines
- Fixes missing Fhir Classes on Release
- Don't show the button to edit the post if the author of the original post is not the logged in user
- Fixes crash parsing multiple results from Amber by @npub1w4u…0jr5
- Fixes the load of edits on a new edit proposal
- Fixes forking information kept from a previous post
- Fixes search on binary content
- Fixes space after clickable user display
- Centers Blank Note when post was hidden by the user.
- Accepts JSON events with escaping errors
- Fixes the parsing of user metadata events several times due to large coroutine backlog
- Fixes Scheduled Tag in LiveStreams
- Fixes the isOnlineCheck for nostr nests.
- Fixes sorting contract issues when follow status and user names are the same between keys
- Fixes tickmarks on dropdowns
- Checks if a Classified is wellformed before rendering
- Fixes size and alignment of the text when the live stream video is not present.
- Fixes some imports for benchmarks
- Fixes infinite Quotation issue (3 quotes are allowed).
- Fixes crashing with too many videos in quoted posts.
- Fixes double Show More when the user has hidden a post and ALSO the user's followers have reported the post.
- Only shows OTS to the respective Edit
- Fixes a bug with the latest version of jackson
- Avoids showing machine-code errors when paying for zaps on external wallets
- Fixes too strict timing constraints for new posts (accepts up to a minute in the future)
- Fixes following of geotags
- Fixes lack of zap amount refresh after zapping a note.
- Fixes videos not being able to seekTo the zero position.
- Fixes layout issues of Blog Post summaries when images are not present.
- Doesn't show edits of blog posts in the User's Profile
- Fixes Amber's deep sleep: Adds a lifeCycleOwner listener to register external signers on resume
- Fixes missing context in some replies to blog posts.
- Adds a space after the Channel header in the reply rows
- Centralizes the counter after the list of participants in a live event.
- Fixes double mention to Community headers when seeing a reply to a community post.
- Fixes Chat preview images when no image has been set.
- Fixes the display or Zap Events when All Follows is selected in Notifications
- Fixes the reply event finder for the reply row of text notes
- Makes hidden cards full width on the discovery feed
- Fixes the width of muted messages on chat feeds.
- Fixes the feed updates after list selections on the Discovery pages.
- Realigns the reaction icons and texts between main feed and video feed.
- Fixes garbled URL preview for non-UTF-8 HTML by @npub168g…2dlc
- Adjusts icon sizes on the galleries
- Avoids publishing with two equal `t` hashtags when the user already writes them in lowercase
- Limits the size of image previews from opengraph from being too big
- Fixes NPE with the cached state.
- Increases the push notification max delay to 15 minutes
- Fixes controller comparison for keep playing
- Fixes tag markers for replies in DMs
- Fixes layout of the reply row in chats
- Fixes lack of blurhash preview in some videos
- Fixes the lack of following mark on user pictures in chats
- Fixes the UI spacing for channels
- Fixes the use of filters that didn't discriminate the relay type setup
- Holds the state of Show More when switching edits and translations
- Renders DMs and live chats in the feed if they show up there
- Fixes contract violation when sorting users
Updated translations:
- Spanish by @npub1luh…q903
- French by @npub106e…r8fz
- Dutch by @npub1w4l…txcd
- Swahili by @npub1q6p…0kxr
- Chinese by @npub1ras…fhd7
- Bengali by @npub13qt…x23t
- Hungarian by @npub1ww8…nvtp
- Czech, German, Swedish and Portuguese by @npub1e2y…3eef
- Arabic by @npub13qt…x23t
- Thai by @npub1tr6…06fl and @npub1vm0…xp8e
Performance Improvements:
- Switches Robohash to Precompiled SVGs in order to reduce the memory burned of creating Strings with SVGs on the fly
- Restructures Data Access filters and LocalCache to use a ConcurrentSkipList instead of ConcurrentHashMap
- Only download video, image and audio files in NIP-94
- Updated hashtag icons for performance
- Avoids checks if a filter has changed before generating JSon strings
- Cleans up User Metadata upon receipt instead of in every rendering
- Simpler/Faster UserDisplay renderings
- Reduces video cache from 10 to 4 videos
- Removes coroutine use for Hashtags
- Brings the ZapForwarding icon to Compose
- Simplifies the algorithm to check if chatroom sender intersects with the follow list
- Avoids serializing temporary fields on Quartz
- Refactors views to the video and chat feeds
- Restructures NoteCompose for performance
- Restructures markAsRead to minimize threading cost
- Adds a large benchmark test for duplicate events
- Optimizing the performance of Highlight rendering
- After memory cleanup, only trigger liveData when it actually changes
- Minimizes memory use to calculate zaps
- Avoids triggering an error when decoding invalid hexes
- Reduces the amount of co-routines being launched in each LiveData update
- Migrates channel list and channel notes to LargeCache
- Removes the use of data classes to speed up comparisons
- Improves Nostr filter to bring public chat messages and avoid public chat creation and metadata updates
- Removes jsoup from dependencies
- Removes the need to observe author changes to event after loaded
- Turns hashtag icons into programmable vectors
- Moves the Following Vector to a native composable
- Removes unnecessary modifier layouts from the top bar
- Uses the cached thread pool instead of the scheduled thread pool for translation services
- Avoids launching coroutines that were just launched
- Makes a cache for Media Items
- Only changes the keep playing status if different
- Reduces recompositions after video/image hash verification
- Avoiding feed jitter when pressing the notification button twice
Code Quality Improvements:
- Breaks massive NoteCompose down into each event type
- Removes the release drafter plugin on actions. Too buggy
- Removes dependency of the Robohash from CryptoUtils
- Improves Preview helper classes
- Updates secp256k1KmpJniAndroid, compose, zoomable, media3, jackson and firebase libs
- Updates AGP to 8.3.1
- Deletes the old Settings local db
- Refactors some of the old display name structure
- Refactors Relay classes.
- Isolates the LargeCache forEach method to allow quick time measurements on filters
- Reorganizes classes in the commons lib
- Fixes test cases for nip96 uploaders
- Removes unused addMargin param
- Refactoring caching systems for the Compose layer
- Aligns the BOM between implementation and tests
- Refactors the use of dividers out of components
- Refactors composables to load events, check hidden and check report
- Fix Kotlin encryptDecryptTest to decrypt with swapped private and public keys to follow NIP-44 documentation by @npub1yau…vjmf
- Finishes the migration of People List updates from LiveData to Flow
- Migrates all Refreshable feeds to the Refreshable box component
- Refactors cache methods in GiftWraps
- Migrates Media3 Videos to the DefaultMediaSourceFactory
Download:
- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.86.0/amethyst-googleplay-universal-v0.86.0.apk )
- [FOSS Edition - No translations](https://github.com/vitorpamplona/amethyst/releases/download/v0.86.0/amethyst-fdroid-universal-v0.86.0.apk )
2024-03-26 00:35:09
by npub1gcx…nj5z
The Web is taken.
They control your data: Servers can change anything you send at any time: E-mails, medical records, private family pictures, social media posts, orders etc. You won't even notice it. Not only they can change, but you can also create new content as if they were made by you. Your history is written by them.
Servers do too much: They convinced us we don't have enough processing power and moved all the logic from our applications into servers. Even though a phone has an equivalent processing power than a single server today, we believe we must use complicated server architectures to achieve anything in the web. Phones are the cloud.
Everything is a rental: You don't own your domain name. It's a rental. Your server is a rental. Your digital certificate is a rental. You don't own anything. Your digital identity is a rental.
Data Silos force you to stay: Moving is too hard. They profit on making things just difficult enough to keep your around. After all, it's just 9.99 a month.
Enter the Verifiable Web
Own your keys, own your content. No one can write for you. No one can change what you write.
Sign everything you send. Every little like, every little key press. If it wasn't signed, it didn't happen.
Verify everything you receive. Trust the signer, not the servers in between.
You decide how data gets to you and where it stays. Your digital history is assembled by you.
Welcome to Nostr
2024-03-21 21:50:05
- reply
by npub1gcx…nj5z
That's why we have the two tabs. So, people can go back and forth when they feel like getting innundated by replies.
The problem of options for everything is that we have to mantain all options working at all times. In this case, new screens, new feed cache, new algos if needed, new ways to visualize (if we want to replicate Plebstr), etc.
2024-03-21 21:13:00
- reply
by npub1gcx…nj5z
Yep...
Relay onNotice wss://nostr.wine, ERROR: bad req: arr too big
Relay onNotice wss://relay.damus.io, ERROR: bad req: arr too big
Relay onNotice wss://nos.lol, ERROR: bad req: arr too big
Relay onNotice wss://nostr.bitcoiner.social, ERROR: bad req: arr too big
Relay onNotice wss://a.nos.lol, ERROR: bad req: arr too big
Relay onNotice wss://nostr.mom, ERROR: bad req: arr too big
Relay onNotice wss://nostr.oxtr.dev, ERROR: bad req: arr too big
Relay onNotice wss://relay.nostr.bg, ERROR: bad req: arr too big
2024-03-11 00:05:28
- reply
by npub1gcx…nj5z
I don't really get your point. Every app is "social" these days. Even health care is, at the core, a social network (you, your doc, your pharmacy, etc). So, what I am proposing is not against what you highlighted.
Every event kind in Nostr can be seen as a separate censorship-resistant social network. So, in many ways, Nostr has already forked itself multiple times. In fact, I do believe every client is also a fork of the network because no client displays **everything** the Network has yet. No client is complete. On top of that, every client does things differently. So, in some sense, they are all forks of the network.
There is no consensus layer in Nostr. We don't select a single chain like we do when we run Bitcoin. So, the idea of forking the protocol itself doesn't really many any sense.
To conclude: Forks are either already happening with all event kinds or it's impossible to fork because Nostr already includes everything. There is no in-between.
2024-03-10 20:30:28
- reply
by npub1gcx…nj5z
"We" is the NIP repo, which provides guidance on how to use nostr. It's not a spec, but a description of what is happening in the Nostr ecosystem.
Lots of clients have proposed HTML encoding in kind 1. Multiple issues are asking for markdown in kind 1. It's just about time for a new client to come and start putting other syntaxes in kind 1. People can add and modify tags for their needs, breaking the past, like what the folks in the PR were proposing.
If we insist on getting every new client, we are just creating more problems for ourselves.
I am fine with it because I will integrate everything that shows up, but many other clients won't be able to manage it. So, I think it is better if we make it optional and more specific to Twitter like posts.