I see to much lazy design, inefficient workflows and unimaginative boolean algebra all over the place, to co-sign that. Once we clear out all of that, what we have left, is the 10%.

Reply to this note

Please Login to reply.

Discussion

Sure. I also see those in virtually every Nostr code base and my own code.

But my users don't care if I have a perfect Boolean algebra or the most efficient workflows. They care about doing the thing they want to do in the best way possible. That's what I am focused on. And I attribute most of Amethyst's success to focusing on them, not on the perfect code.

You underestimate how many of us want to use it, but can't, due to performance issues. It can be so frustrating.

I've installed and uninstalled it, at least 4 times.

But, that's okay. I have my own devs to nag, now.

Aargh! But it drives me nuts, cuz you have Citrine and Amber and could be a real performance monster, without crimping the feature set. 😂 🙈

Okay, okay, I'll stop whining.

Did you try Yana and Voyage? Those are much faster than Amethyst.

I didn't say I am unaware of the performance issues we have, but for some devices, people just won't be able to run Amethyst. It's not designed for them. In order to make some stuff work in some phones, I need to make things worse for everybody else.

For instance, loading could be much faster on Amethyst, but I had to reduce the speed to minimize battery drain. So, it usually takes a second between the event coming to the phone and a screen update, instead of updating the screen immediately multiple times a second as things come. In this case, I specifically chose a slower approach to expand the number of devices we can run on. And that was terrible for some users. But most people didn't notice at all.

But that has a limit. After some point each percentage point in coverage might make things more visible to the rest of users. I am constantly searching for things that don't affect the other users. The easiest one is to just remove all of our feeds and features.

For instance, if I don't load NIP-17 DMs, then the app is already almost 5x the loading performance simply because receiving DMs and building the user list for of the latest chats is quite a task (decrypting every message).

I've tried Voyage, but it sacrifices too many features to compete with Amethyst.

I bet you could tie more performance improvements into the low-data mode and let people opt-in to it. I don't use the DMs, for instance. The once per day, that I check them, I can manually trigger the fetch.

I actually bought a new phone, just to use Amethyst, and then I got crushed by spotty mobile Internet. Tighter integration with Citrine and automatic network diagnosis could potentially make moving in and out of the connections seamless.

Agree. We need a better integration with Citrine. But citrine also needs to be faster. Even strfry running on the phone is slower than pinging a server if citrine/strfry needs to go to the disk to get something... Servers generally keep everything in memory.. so they reply super fast.

We will see. Now with outbox I am also doing a broader filter redesign to minimize asking the same stuff to different relays. The new issue will be that many people keep 20+ relays in their list and that means that the app needs to search in all of them to not miss things.

Ah, but you're thinking of performance as merely being speed. There are different aspects, like reduced bandwidth usage, computation minimization, constancy, etc.

What Citrine can do is smooth out fluctuations in the connection strength. If you were background-downloading into Citrine, while in a fast connection, and then pulling from it, when the connection faltered, then the user wouldn't even notice the fluctuation. He'd just scroll up and see the next post. Scroll up again, see another next post...

Yeap, but citrine is quite slow. If you add citrine to your local relay list, force close amethyst, go offline and open the app, you will see how slow it gets. So, most of the time we receive the event from servers faster than this local relay. StrFry Android is faster than citrine, but you will need to learn how to install in the command line.

You grossly underestimate how crappy my Internet sometimes is. 🙈

It was friggin brilliant to put a relay on Android. I don't doubt that it can be made even moar brilliant.

Even a slow relay solves for concrete problems. I read books and magazines directly from Citrine, even without an Internet connection.

Hopefully, somebody makes a book client that doesn't need any of the stuff Amethyst has.

nostrdb will always be faster then strfry or citrine, and you don't need to install any separate app

Or that.

But an Android relay is pretty darn awesome. It always feels like a miracle.

it makes me sad because back in 2018 i was writing code on android cointainers but that whole thing evaporated.

i was homeless and had nothing but a sony experia and it let me do that back then but they basically killed the whole genre.

good luck finding a device that can run cyanogenmod now. in 2016 there was many. the scumbags basically shut all that down because of course they only want to serve their masters in langley and whatever the place is that mi6 is centered. b something

Put the nostrdb on a relay app, then. You don't even need a UI for that :)

it would be slow if it was in a relay app. you pay the cost of sending it over a socket, parsing, etc.

with nostrdb its a single btree lookup into memory with a cache aligned struct pointer

Split it in two and make the relay available and the cache as a separate lib. It would be similar to what I and the web stacks are doing these days.

Also, opening Amethyst could trigger a mass-download from lots of relays into Citrine, and then Amethyst could just look to Citrine first, after that.

And voyage already has way more features than notedeck as of now.

I just wanna make libraries … with clean code that any client can implement.