I think it is mainly because the frequency of their bot hit the relays quite a lot thus looks like suspicious traffic. If i'm not mistaken they also access relays using various location (Europe, Asia, America) maybe to make sure their reports are correct (online relays reports)
Yes, because map is part of Javascript Array built-in function. It's not available for other data type.
I have seen them crawl and check any active relays (including relay) they don't have any clear details. We can only tell if we check reverse domain of the IP visiting our relay. Nostr.band has better signature with origin header crawler.nostr.band when they connect. Although, any headers value are note really reliable becausr anyone can also fake it 😅
I think the best we can do if we missed a lot are checking nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk 's Daily report. They have summarized quite a lot of important events in Nostr. 🙂
If we can create our own custom algorithm then personally i will create:
1. Recommendation feed based on my topic interest. This can be started with analysis of users preferences (topics that they likes/zaps/reposts/comments) assuming we have topic classification (manual label or automated label) data on each notes/posts.
2. "What i have missed". Thankfully one example is already exist which is Pablo's DVM. It analyzes user activity time and check when they were inactive (have no posts/interactions) and will suggest notes that were posted by other users during their inactivity.
3. "Feeling lucky". This is similar to point 1 but instead of directly give recommendation based on user interest, it will give recommendation topic a bit outside of user preferences based on other people's preferences they have interacted with. Example: Alice likes Sport and Business. Bob (Friend of Alice) likes Business and Science. Charlie (Friend of Alice) likes Business and Travel. The algorithm will give Alice Science and Travel topic based on intersection of common interest (Business).
Just a little bit idea nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 , maybe Damus with Nostrdb can achieve that 😅
Oh, i see. It's fine if you want to do some experiments. Please, keep your curiousity, don't kill it. 😄
It will be helpful especially if you documented all the experiments in some notes/blogs/posts as references for other people with similar cases. 🙂
Oh, nice, you can probably add them into 0xtr onion relay repository list 👀
https://github.com/0xtrr/onion-service-nostr-clients
Why do you want to add extra TLS? Is it for benchmark? I think it only add extra overhead in encryption while only gain minimal benefit. Nostr relay seems doesn't really need double encryption because its data already protected with signature 😅
https://blog.torproject.org/tls-certificate-for-onion-site/
Did LetsEncrypt announce their support for .onion TLS certificates? Probably i missed them, i thought it was still in draft?
Yes, via NWC settings in Mutiny. Although, in my experience sometimes i need to open the minimized browser (Mutiny PWA) to make it really work (have quite delays) 😅
"Do what you love, and love what you do."
Passion and patient.
Have you tried with tor hidden services? I think it will be similar in seconds latency, but maybe a bit faster 😅
I have no experience yet using i2p, maybe want to explore that later
Oh, nice, how is the result? Latency and reliability using i2p compared to regular network or even onion hidden service
Oh, nice, that is a good mid entry phone, can be a good minimum test device 👀
Is it Redmi 10 or Redmi Note 10? The price seems quite different from average
https://m.gsmarena.com/xiaomi_redmi_10_2022-price-11357.php
https://m.gsmarena.com/xiaomi_redmi_note_10_5g-price-10768.php
Looking forward to Damus Android, Will 🙂
I think it is always the best to support low possible OS and devices.
Amethyst for example support minimum Android 8.0 (SDK 26)
For device testing, if possible test the app with low performance budget device such as Redmi (Xiaomi) which popular in developing countries (India, Indonesia, etc). If the app can run smoothly in low performance device then it won't be slow in high performance device (Pixel, or any Flagship phone).
Too confusing? 😅
Similar to Brazil, Indonesia has various payment providers (Gopay, QRIS, etc) using QR Code which used easily by many Indonesian merchants and buyers
Is that your relay Ingwie? 👀
Here is a demo of a new onboarding flow for nostr applications. I started working on this after watching nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240's keynote "Nostr for normies" at nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l; which I highly recommend watching.
My goal here was to create a way to onboard new users without requiring them to:
* install a browser extension
* copy/paste a secret
* explain npub/nsec stuff
* without losing interoperability with other nostr applications
This flow resembles a lot an OAuth style (e.g. "Login with twitter") flow:
* You create an account in one site (e.g. Twitter)
* You can "login" to another site with that account
* You can revoke access from using your account
Behind the scenes this is using NIP-89 to find nsecBunkers that allow people to register an account in their domain.
This means that any nostr application can offer a signup/login flow on any nsecBunker domain. The application itself doesn't take custody nor ever see the generated key.
And what's cool is that any nsecBunker provider can create their own flow; they can use passwords, or not, they can require a payment or proof-of-work to create an account. They can brand their "signup/login" popup page in whatever way they want.
Here is a demo video of this new building block that is now available to nostr applications.
https://cdn.satellite.earth/2e2e353ac5f69caffdc73da81c4e735c19579432967323564924c585819e6ef9.mp4
Awesome work Pablo, really neat and much easier flow. Thank you for the works 👋