Watching nostr:nprofile1qqspnzgrfett3asxcuj0gksje6z2zxzpvgd27uvz58m9vsuqh8zzw6cpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgjwaehxw309ac82unsd3jhqct89ejhxqg5waehxw309aex2mrp0yhxgctdw4eju6t0rjj54p live stream via Tor without any delay is weird
nostr:naddr1qqjrgcf5vgexvvrp943k2wrr956xywpk95urqwfn94nr2cejvy6x2de5xyckyq3qeaz6dwsnvwkha5sn5puwwyxjgy26uusundrm684lg3vw4ma5c2jsxpqqqpmxwcyy4sp
Running push notifications is so cheap.
We are currently serving 48,216 public keys that activated Push from 4046 online relays at an average of 3 DMs/Zaps per second for $34 dollars/mo.
That's $0.0007/user/month.
And I am running this with a single javascript server on Heroku. It's neither optimized, not the cheapest host.
It's not a dependency for Nostr. It's a dependency for Amethyst. Connecting to random relays with all of our filters is extremely bad. But that's just us. All the other specialty clients are fine.
In-device video translations > filtering content by language
nostr:nevent1qqs24u39w8jwv4z8nw9yjlc5ygkhne63hkc4euxa9863nm6kdh4fgdspz9mhxue69uhkummnw3ezuamfdejj7q3qqny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysxpqqqqqqz8kws2v
What do we need to do to get Blockstream's BTC explorer API to respond through Tor?
This is how we validate Open Timestamps in Nostr without running a Bitcoin node in the phone.
https://blockstream.info/api/block-height/862901
Technically, my title is from UFRGS in Brazil because I didn't want to pay MIT to become a real student and get the certificate.
But I did spend 2 years at the MIT Media Lab as a visiting PhD student, got from idea to 90% of my thesis done while there and later fundraised my spin off company from that lab.
Now that we have Tor enabled by default for untrusted relays that are not in your list, I feel much more comfortable in going full outbox model.
Future is bright.
Who is the client that is automatically adding 100s of relays the user's inbox and outbox lists?
Seriously, that's not what these lists were designed for.
Their main one, but this one doesn't work if Orbot is running and Amethyst starts after it....
Orbot seems to use it in a similar way, so I don't know what might be causing the issue.
https://github.com/guardianproject/tor-android
Doesn't work. Videos take forever to load, many relays block it, profile pictures don't load, and streaming videos snag all the time.
Tor is good, but the all or nothing doesn't make much sense.
We are almost there...
Final annoying bug... When using Amethyst's Tor alongside Orbot, if Amethyst starts first, then both Tor connections work (and you can choose which one to use).
But If Orbot connects to Tor before Amethyst does, only Orbot works. Even though Amethyst got a separate SOCKS proxy/port from the Tor library, all tor channels immediately close.
🤔
I got to the point that Amethyst can now run two background video playbacks, one with Tor and one without Tor, at the same time.
That would happen when two videos are on the screen, one with a .onion address and another with a regular URL and Tor is disabled for video playback OR when two videos are on the screen and TOR is forced for videos, but one of them is coming from a server in the phone, which must use clearnet.
Background services are account agnostic, but listen to the currently active account to get the Tor settings from.
Edge cases, huge complexity, but this is the right way to do it.
Somewhat on purpose. We don't have great explainers for the NWC setup yet, so hiding it and forcing people to ask the network for help was the easiest way to activate personal support to explain what it is and they need to do.
It's kinda the opposite take of the Relay Settings screen.
I am unhappy with both cases. If we explain the options in a UI, it's too much work and people just give up. If we hide, it doesn't really get that much use.
Anyway..
Not likely. I think we need to break it down into many dialogs and place each dialog in the part of the app that uses those relays: dm relays on DMs, search relays on search. I just don't know what to do with the outbox ones because there is no screen that uses them (they are made for your followers, not for yourself).
Yep, but we need to be careful on the recommendations to avoid taking liability and centralizing the ecosystem on them. Ideally I would just send people to a website designed to evaluate relays to see which ones match their needs.
But we may need to do that service inside the app.
The Zap Event is sent by the receiver. Sometimes the receiver's Zap server is off-line or too busy. Or the receiver might not have a Zap service at all and in that case, they receive but Nostr client never gets anything.
Yes, that is how it should be. We are just not there yet. The app is still getting confused between the outbox model and the rest of the relay lists. But we should be able to fix it.
I hate my voice, so you tell me if this is any good. 🚀
nostr:naddr1qpdyun6n23fz6s6p2py4gs2vf9f56t25fpzj63j42324y3fdfarz6560gdy5znpdf4z5gj2p94mkjarg94tyj4z02gk4qs2d2pxy7njp942ys3fdgf5hgcm0d9hz65r0v33kzum594exxutg8p5sygxy3c5lqj6g9nqpeg0ea7xgdmurrrq9nc8fx5er2930pq8jdc2vzypsgqqqskas9rwfp4
Our goal is to make self-custodial personal storage relays as easy as Google drive/Apple cloud.
We don't need to connect to them all the time, but they must be there if we truly care about censorship resistance.
They definatly have to pick their relays. If they are just gonna go with whatever the client says, we can all just stay on centralized twitter.
Picking relays is the reason Nostr is censorship resistant. If you abandon that as a user, there is no point on any of this.
If it's not open source, it's not private.
If you can't choose to use your own server, it's not private.
If you can't use it when the company is gone, it's not private.
If you can't create anonymous accounts, it's not private.
Stop trusting the marketing. Start verifying.
Notes by Vitor Pamplona | export