Unless software starts needing 128bit architecture I don't see why I would need to upgrade 🤔

I self host so many random things I'm not even close to using up all the cores yet

If you drive a car newer than 2019 or have an electric car, you are the problem & need to be removed.

I’m less concerned about the year of the gas car as it relates to violent removal from society. We can work with you.

But Electric. We need to hunt you down, fold you into some luggage & get you on the next plane to the middle of the ocean.

ok, so just need a list of supported protocol names in the nip-11 then

yeah, i think add a field to nip-11 info that gives a codec name

the other thing to be attended to is the websocket negotiation, possibly a new field in the header would be useful such as a mimetype, if it's upgrade and json, then json, if it's upgrade and cbor, it's cbor, etc

i think better we don't tamper with the API though - retain the envelopes, just in a different encoding

i also have been saying for some time it would be useful to add a negation operator to filters so a client can request to not see events from authors or events it already has... a lot of what negentropy does is working around this problem also

and maybe a new variant of req that only returns event ids instead of whole events

anyway, now i'm going off on tangents

This is really cool. I see exactly what you're saying now.

This (as I think you said earlier) could just be a simple optional NIP that relays could signal support for and they'd handle the data however they want on their side right?

Uploading from the account page specifically seems to remove color profile data for some reason.

It appears to be a color space issue. I’m having trouble reproducing it at the moment but I’ll update this post when it happens again.

Apparently I'm one of those morons. Why wouldn't you want to use CBOR?

Is your solution just to binary encode most of the json event to squish it down but then keep an id/sig (and maybe a tag) unencoded? I'm not sure I'm following what you're suggesting. There's too much vitriol mixed in with the ideas. 😅

2. No.

All chips have some sort of hardware boot ROM, from your CPU to a Raspberry Pi to the STM32s used in a lot of HWWs including CC.

RPi boot ROM cannot be modified and such an attack would need to target your Pi specifically, which is impossible, and then somehow figure out a way to detect SS code and add a backdoor.

1. Yes, lol, "is it secure" is a simpler way to ask.

2. I tagged NVK, founder of coinkite.

3. Thanks, do you think NVKs critique of broadcom chips on raspberry pi have any merit, and is it a valid argument against Seedsigner?

and hey, thanks for taking time to reply. 🙏

1. Yes.

2. I've no idea on his thoughts. He has a 🐱 habit of blocking all his competitors so they can't call him out his intellectual dishonesty. If I was a betting man, the criticism would likely involve the word 'cloner' at least once.

3. He has me blocked, so I've no idea what his critiques are, but I do know that Keith Mukai recently posted a Gist as rebuttal (of sorts). I haven't read it.

you can't do that... it's a chicken and egg problem

if you are going to make a canonical binary encoding, exactly the same as the json canonical you do not hash on the hash (obviously) or the signature (also obviously) but when i say obviously, you don't realise that until you think about it

the ID and signature are external to the event, even if they appear in the naive version sent over the wire, that is only there really for fast access, a convenience, but to make the hash again you remove the signature and ID from the event and remove the object keys and replace it with a strict faithful ordering as received otherwise

the same rules can be applied to a binary encoding, so a hypothetical "b" tag could be added with other variations but if the signature is missing that is not an available verification method, so fall back to the json canonical for that, as the signature field is also present there, and would be retained in a binary wire format for the same reason (legacy, perhaps, but probably it will never go away, and good i say)

so, yeah, in summary IDs and Signature fields are inherently external to the data, thus they can be added or removed with impunity and if we were to propose a NIP to use them, this makes it simpler to explain, "b tags must not be added in the canonical form to derive the json ID hash"

in this way the event can be sent on the wire with this binary signature on it, enabling the forming of the binary encoding corresponding to it later, but it has to be omitted

so, yeah, maybe that's too complicated for people's brains, but ultimately that's how it would have to work

why not? tags are just lists of strings?... i can picture `["b","","",""]` in keeping with existing layouts

yeah, that's what i'm saying but just make it a tag so clients can generate it directly as well

i would prefer it if there was no new fields in events

as for filters i have said that "it would be useful to have a negation operator, eg !"

We can have alternative signatures in a specific parameterized single letter tag

Labeling events could be used to augment missing tags after the fact

IMO a common precompression dictionary would be even better and simpler

The canonical form, also, is better, there really is no need to transmit the event id