Because not everyone here wants to fight the war between two large prison camps for totalitarian clown offshores.

Anyway, so you are a pro-qasabian troll, understood. Muting.

Another qasabian propaganda victim detected, ok. Or is gazprom paying you in bitcoins to spread this BS?

Until it won't.

You don't seem to have a slightest clue what was and is going on in Ukraine. Transfers of power never have been democratic here since 1999, when Chornovil was killed. Germany didn't organize this killing. Russia did.

*ink leaks.

And yes, the best privacy-friendly device is a pocket notebook with a good fountain pen attached. I'm serious.

Pilot MR is awesome but its feed assembly is friction-fit, so isn't really EDC-able as the knocks can lead to in. Lamy Safari looks too bulky, although I maybe will try it out as well. Kawecos are not really an option where I live. Jinhaos are a lottery. Any other suggestions? #asknostr #fountainpen

Thanks, will take a look at these options.

By the way, I don't understand why the vendors who no longer exist on mobile phone market (e.g. Ericsson, Siemens) are so greedy and don't release the source codes of their flashing tools and/or their protocol specs, for people to be able to maintain the firmware of their still working hardware from 1990s-2000s themselves. Come on, you have already lost everything on the market, why take the devices to the grave with you?

Flashboxes are the greatest scam of three previous decades. But it only became possible due to manufacturers' greed.

OK, all this is good but I really need to talk to someone who's into featurephones topic. #asknostr

I'm stuck on several directions of reverse-engineering:

1) MT6261:

- decrypting/unpacking MAUI partitions (**besides** ALICE_2)

- an open source way to flash any area (don't point me to Ubuntu FlashTool version please, the libflashtool.so is not open source)

- META mode (protocol, commands, everything)

2) MT6276: handshake, dumping, META mode (protocol, commands, everything)

3) SC6531 (any revision): diag protocol, direct NVRAM access within packed ROMs

4) SC770x: handshake, dumping, FS structure

5) UMS9117(L): handshake, dumping, FS structure

6) MT6572: flashing (low-level), META mode (protocol, commands, everything)

7) MT6731: flashing (low-level), secureboot bypass, META mode (protocol, commands, everything)

Any piece of information on the above topics would be extremely helpful for the development of FOSS featurephone customization and malware removal tools.

Also, if anyone has a full flash dump of CAT B26, I'd appreciate it too to be able to repair mine.

It depends on the network, actually. Where I live, over around 15000 phones with zeroed-out IMEIs are estimated to circulate in the networks and no one (almost) gives a damn. It's the combination of IMEI + IMSI, not IMEI alone, that identifies the phone.

Some other countries explicitly block zeroed-out IMEIs, I know that too.

What is the cheapest non-Nokia featurephone you can get now? Chances are, it might have an IMEI editor built-in.

Still BETA than nothing.

Wanna talk about that? (specifics of Eastern hemisphere apply, mostly GSM or 3G phones)

Thanks. Custodial options are out of question. I'm also thinking about Blixt: it's not on F-Droid but is open-source and available for store-independent APK download.

So, the idea theoretically can be implemented, after all. Now I really have a lot to think about. :D

30023 might work too. I mean, for source code storage, one could even choose 777777 to be sure not to clash with anything else.

I understand, but "no one uses anything else other than Git" is a sheer example of narrow-mindedness. I think this platform deserves better curators.

Anyway, if we put the version info into tags, nothing is violated and this information will be relayed for sure. And such notes wouldn't be for a "normal" client consumption anyway, so, like they say, "it has a chance of working".

Now, THAT link contains some real nonsense.

Side question: how do current public Nostr relays treat event fields they don't understand (and that don't participate in the event signature)? Are they discarded or saved "as is"?

Is discarded, then any new fields must reside in tags, which is not very convenient for performance. If retained, then there is a chance to just extend some clients.

Come on, NIP-01 still is in draft. I think *every* event should be (optionally) versioned, with the most recent version being the "source of truth" unless stated otherwise. Current clients can just ignore these fields if they don't want this functionality...

I think "This specification is designed to provide the foundations by which file hosting and version control, akin to GitHub or SharePoint, may be implemented on Nostr." sentence was a bit excessive. Versioned documents exist in much more domains than just these two.

Also, why not just introduce optional "prev" and "ver" fields to NIP-01?