I'm cautiously optimistic about some reported performance issues being fixed, too. Congratulations!

Snort was a pain to use recently as content took many minutes to load. Notifications for example would remain empty for three minutes straight. This is currently faster than ever.

If gossip is the way, clients are heading, we probably should also use that for our relay.

Mobile clients still have a hard time keeping dozens of websockets open all the time so I think there will be demand for relays that get the events you care about for you. But "follows of follows" is probably too simple an approach.

Legacy apps where the devs have the keys certainly have an easier time migrating off Play Store. They "only" have to convince their clients to enable "untrusted" sources and download updates from their websites. Users can then update, knowing the binary was signed by the same devs as before.

New apps essentially have to start from zero and tell their users to install that other app if they loose their Google Developer account. Clients cannot upgrade from the Play Store version to the free version. They have to either delete the Play Store version before installing the free version or the provider has to provide the free version under a completely different app ID.

And then there is the issue with Google forcing devs to use their APIs for push notifications for example.

And they have good excuses for both but these excuses assume that Google never is evil and is available for all Android users.

I'm an Android dev since day two (2009) and prefer it over Apple but Google is also going for more wallet garden.

It used to be such that developers signed their apps with a key that never was shared with Google. Then they let developers opt in to sharing that key with them and now I think, to distribute on Google Play, new developers don't get their hands on the signing key.

The consequence is that if you publish on Google Play and with direct downloads from your website, you have to sign with different keys or risk to not be able to provide updates if Google gives you the boot.

At first I thought they sent you a CD or something :D The sticker is cool though.

Wonder if Greenpeace will ever be embarrassed about having produced those stickers and sent them to people.

Poked too many bears?

When youtubstr?

You should get the latest version. The project forked, so ...

https://void.cat/d/VZApJESb7ee17KrgrNi9dp.webp

Working the fiat mines?

Sounds like constructive criticism.

Not sure where you see this Reddit community. For me, it is a million communities. Each sub is a cosmos of memes and rules and acceptable styles.

The fix was not the hard part. Just not using JSON.stringify() was good enough. The problem was that I had empty sets for other reasons so I tested just those 20 LOC with a console.log in the end and I was scratching my head for half an hour why the set was empty all the time.

TIL:

console.log(JSON.stringify(new Set(["bla", "foo"])))

prints

{}

which does not mean that the set was empty.

ChatGPT found it after three rounds of finding errors that were no errors at all and

> I apologize for the confusion. Upon further inspection, I see another issue in the code.

Here in Chile they sell IQF minced meat and the following video is ten years old. I bought my first and last bag of IQF minced a year ago. Feels more processed than the locally minced from the fridge.

https://www.youtube.com/watch?v=kcJDyoULWsg

With WalletScrutiny.com we focus on impact. As much as "Just build it yourself. It's easy" isn't a good excuse for stealing from the 99.9% of users that will not compile it themselves, offering alternative downloads doesn't fix much. So if you offer the apk on your project's website for download, most users would be more vulnerable due to phishing attacks than if you figure it out with one repository - Google Play Store.

There is one alternative though: Fdroid. If your project is open source, you can publish it via fdroid and benefit from fdroid checking for reproducible builds.

So ... naturally, third parties cannot reproduce bit for bit of an Android executable APK file as it contains the signature which third parties cannot generate. This is why when testing APKs for nostr:npub1j9kttlc86w63emmldd4h74rekyqpksqup6p9trhp5gjsf374qlyszvuswx we have to take a bit more efforts and thus have to make more assumptions than when there is no signature.

You compared the sha256sum hashes. If those match, the files match or whoever knows how to generate hash collisions could get filthy rich mining Bitcoin.

The APK is a zip file. You can literally rename it to app.zip and unzip it. Inside you will find the signature in a folder called META-INF. Content in that folder is not covered by the signature, so you could put some "malicious" files there, zip it again, rename it .apk and Android would load it as a good, signed by the provider app. Android should not load or do anything really with your "malicious" file but ... that's the assumption. Maybe some payload could be planted that could confuse Android to still do something shady.

Anyway, the app's sha256 fingerprint depends on not only the compressed content that could vary in the META-INF folder but also on the compression itself. I don't know why but I did observe different hashes for same versions of the same app even with both obtained from Google.

All that said, to diff two APKs, use unzip and recursive diff or use diffoscope. If you find diffs only in META-INF, you should be good. In your case you should not find diffs in META-INF neither as you expect the same signature.

That "oil" is butter I hope.

created_at ranges from 1620799628 to 1686364020 but I suspect some back-dating there so let me clip those first 1000 events ...

1685927349 to 1686364020. 5 days, streamed from damus, probably with pauses with changing but mostly not very aggressive filters.