Although it is not OSI approved, the license theoretically didn't add any more restrictions beyond attribution, which stays in line with The Open Source Definition.

That's debateable. How about, e.g, "10. No provision of the license may be predicated on any [...] style of interface."

Anyway, if it was clear cut, it shouldn't be difficult to get it approved.

These kinds of discussions show why it's a pain to use non standard licenses.

Prisma Next will be... Drizzle

(not that much though)

I love the idea of DOs and I'm happy to see an OSS implementation.

Would it be interesting to write about comparisons against Cloudflare Durable Object to the project README? Both for clarity and marketing reasons.

Thanks! Any questions in particular on the comparison?

Theory, performance, self-host option, estimated cost, etc. And I see you can deploy rivet on Cloudflare DOs. What situation does it help when we can just use wrangler?

By the way, Cloudflare DO is actually self-hostable with workerd to my knowledge, but it's not an out-of-box experience.

limited by title length XD

Nice bad story. Make up one better next time.

That you think this is made up shows how little you know about what the Chinese netizen deals with day to day.

It is very real and I am not surprised at all something exactly like what op said has happened.

What if I say I AM a Chinese netizen, right here in China Mainland talking to you?

What if I say no application on my phone ever turn my camera on without my prior approval? What if I confidently say the data privacy situation in China is not in any way worse than USA?

You say I'm censored by gov. Yeah, and so do YOU. We are quite the same, so don't laugh at each other.

If you ever allowed the app access to your camera then next time it will be able to access your camera.

No one is suggesting the app need have circumvented standard android permissions. I'm saying it is not surprising the app would try to open the camera on violation of rules.

You might be surprised to know that I do not disagree with what you said. When it comes to data privacy your information is safe from other private companies but not the government.

> You say I'm censored by gov.

When it comes to political inquiry? Without question this is more sensitive in China. My point is that in China apps are coerced to reveal information about their users to a degree where actively trying to take a picture would not be surprising, or much of an escalation. Not that it would be needed anyways since Internet usage is tied to ID.

I personally treat it as a supply chain risk, as there are no longer any way to report any bugs and security problems.

Then why not provide one yourself?

Forking is a good option for companies, but not a good option for sole developers: one doesn't have that much energy.

Switching to other libraries like requests and aiohttp and supporting them by contributing is clearly a better option.

https://github.com/MarkusSintonen/pyreqwest is a great alternative, much more performant than requests/httpx/aiohttp, and provides an easy httpx compatible wrapper for migration.

No need. There are plenty of other active alternatives

_My_ supply chain is not a big deal, lol. But this is HTTPX. A network library that has a considerable number of users.

When I say _considerable_, I'm essentially saying _nearly every_ big tech. The one I can tell for sure is OpenAI (not a fan of them though).

Remember xz attack?

Why can nearly every big tech take care of their supply chain? :)

Clearly, the maintainer doesn't want to do this job anymore, and it's not a requirement when releasing your code to also do stuff unrelated to programming.

The parent poster never said it was. They just claimed it's risky for them which I agree with

Always happy to see improvements on explanable LLMs. Congrats!

Officially they state they only support 2 latest versions of chrome. But considering their support of IE11, that's actually a lot.

It's a pity that the GitHub repository is not mirrored, probably making downstreams broken.

Good move anyway.

It's a simple `git remote set-url` to fix it, unless you are using some github proprietary API which is the kind of vendor lock-in they want to avoid.

It forces people to update their fetch URL to the proper authoritative repo, which is a good thing.

The AOSC team is working on website i18n recently, so check back later!

You can visit the [wiki](https://wiki.aosc.io/) in the meantime.