Craziest thing I saw at work was someone using AI generated text in a farewell card. Like it's so obvious, it's so much more offensive to send someone an AI generated message than to just not send anything at all.

Just got a few recommendations by my colleagues on LinkedIn that were clearly written by an LLM, the long emdash was even present. But then again, the message was tuned to specific things I did. Also they were from Eastern Europe, so I imagine they just fixed their input.

If you call yourself a writer, having tell tale LLM signs is bad. But for people who's work doesn't involve having a personal voice in written language, it might help them getting them to express things in a better way than before.

We don't know if AGI is even possible outside of a biological construct yet. This is key. Can we land on AGI without some clear indication of possibility (aka Chappie style)? Possibly, but the likelihood is low. Quite low. It's essentially groping in the dark.

A good contrast is quantum computing. We know that's possible, even feasible, and now are trying to overcome the engineering hurdles. And people still think that's vaporware.

> PRECISion · You may find yourself wondering why the IETF waited until 2025 to provide help with Bad Unicode. It didn’t; here’s RFC 8264: PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols; the first PRECIS predecessor was published in 2002. 8264 is 43 pages long, containing a very thorough discussion of many more potential Bad Unicode issues than 9839 does.

I’d also suggest people check out the accompanying RFCs 8265 and 8266:

PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols:

— https://www.rfc-editor.org/rfc/rfc8264

Preparation, Enforcement, and Comparison of Internationalized Strings: Representing Usernames and Passwords

— https://www.rfc-editor.org/rfc/rfc8265

Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames:

— https://www.rfc-editor.org/rfc/rfc8266

Generally speaking, you don’t want usernames being displayed that can change the text direction, or passwords that have different byte representations depending on the device that was used to type it in. These RFCs have specific profiles to avoid that.

I think for these kinds of purposes, failing closed is more secure than failing open. I’d rather disallow whatever the latest emoji to hit the streets is from usernames than potentially allow it to screw up every page that displays usernames.

I'm not certain... On one hand I agree that some characters are problematic (or invalid) - like unpaired surrogates. But the worst case scenario is imo when people designing data structures and protocols start to feel the need to disallow arbitrary classes of characters, even properly escaped.

In the example, username validation is a job of another layer. For example I want to make sure username is shorter than 60 characters, has no emojis or zalgo text, and yes, no null bytes, and return a proper error from the API. I don't want my JSON parsing to fail on completely different layer pre-validation.

And for username some classes are obviously bad - like explained. But what if I send text files that actually use those weird tabs. I expect things that work in my language utf8 "string" type to be encodable. Even more importantly, I see plenty of use cases for null byte, and it is in fact often seen in JSON in the wild.

On the other hand, if we have to use a restricted set of "normal" Unicode characters, having a standard feels useful - better than everyone creating their own mini standard. So I think I like the idea, just don't buy the argumentation or examples in the blog post.

> The message doesn't have any warnings on it like "oh I know it's been a while" or "you might not remember me".

Yes. I do this too and wish more people would.

The qualifications, the "what have you been up to?"s -- such mind-numbingly boring conventions. Who wants to go through a "catchup" interview before talking about what's interesting. If that's the price, it's not worth it.

> decided to trademark your project name

I decided to protect the name because I liked it and wanted to build upon it in the future. Be it OSS, or further commercial offerings.

I hoped to get also protection against corporations that just try to register the name or very similar ones and then decided to get me deleted or sue me for infringements.

In EU it's first to file principle, which means whoever holds the mark, has the right. This means if I would not have registered it, the company could just register "Deepkit" or "Deepki" and sue me to death. Now that I lost the trademark (not totally final, I can appeal), I risk getting sued for having a too similar name - which is exactly what I tried to avoid by having a registered trademark.

Did I make some mistakes with appealing and not collecting enough user data? Likely. Was it too naive from me? Yes. But I think reasonable and the whole idea behind trademarks is to protect projects like this. I could be wrong though, am not an expert.