figassis

It's always been the purpose of ads, and this is how google was. Then they started making it hard to tell ads apart from content. When OpenAI starts injecting subliminal ads into your responses it will effectively win the manipulation battle and also have full plausible deniability becuase there is not even an algo you can point to.

idk, taking free stuff on principle is not a thing that's done everywhere. Time is costly. Reading crap content costs me more than the money I'd pay for it.

I'm not sure if they're irrational. Payment/subscription fatigue is a thing. Today it seems like you have to pay to breathe. It's suffocating. I often go through periods where I reject every money ask compulsively, the same way as I would "disconnect".

It's quite interesting how quality of life gets inverted in non intuitive ways. If you travel to a "developing country" you notice you are no longer bombarded with ads. Watching YouTube is close to the premium experience, bc the country presents no ad revenue to Google. You then travel to a "developed" country and you can't watch a 5 minute video without watching 2 ads.

Everything is a transaction, it is too easy to transact. People used to just write, to just make music. Sure, they need to eat, but they lie. You hear people that make insane amouns of money asking for a coffee. imho, writing is a thing you to to share knowledge, to have a conversation, to learn, etc. It is a way to also get people to know you better, and maybe learn about the things you do that they would want to pay for. So unless writing is your full time job, asking money for it leaves a bad taste.

I would definitely pay a monthly subscription to help fund a non profit compete with Anthropic and OpenAI. I already pay subscriptions for myself and 2+ other people. It's a non brainer to be able to pay for the training of better models that I can then run myself for many more. I hope someone starts this, I think this model would work. I'd start it today if I had the team and initial capital to bootstrap the infr. I know VCs won't fund it, but we definitely will, enthusiastically and continually.

Today you could plug this into your agent as a second brain to give it more insight on related topics and ground it's responses when doing research or building products that can benefit from cross polinating between fields.

The naysaying here is insane. Should a project like this not exist?

How long until Tesla buys Mistral?

Also, Software engineering is engineering. Not all software if built through engineering. I'd say today almost zero software is built this way. Figure it out as you go is not engineering. But I'm sure at NASA people are doing real software engineering.

https://brainbound.blog/dams-animal-engineering-impact

I could be stretching, but to me, this is very conscious and intentional work, perfected through experience and there are many way to get it wrong. What exactly would we call this?

Ok, then there is regulated engineering and unregulated engineering. If you are doing engineering and it's not regulated (for many different reasons) it does not make it any less engineering. Animals do engineering, insects go engineering, it is based on science (empirical), whether they know it or not.

We need to stop redefining terms.

The author is basically saying if you participate in any part of the encryption process, you're deceiving users in saying things are e2e encrypted.

Isn't this conflating encryption with trust? Of course whoever claims to encrypt your data needs to be trustworthy, and whether they actually are is another matter, but If my app allows you to generate a client side key, export it and use it to encrypt data client side and we only get the encrypted data, that is verifiably valid encryption.

I could be malicious and also send a copy of your actual plaintext to the server as well, but that is trivial to check (unless I'm being targeted and I am the only user that gets the malicious code, still, I can check). It's a risky proposition for an organization with vested interest in being seen as pro privacy.

But I get it, different conversation if the government coerces you, and the outcome depends on your bank account and ability to handle pressure.

Lookup MOTO for credit card payments. I know, goes against everything you’ve been told about security, PCI, etc., but yes, it’s a thing. I hope it dies, but the world moves slowly.

VHDL, VLSI are well documented languages, with well build test and verification frameworks and harnesses. Even just by iteration you could get there if you have the money to pay for it.

My country, Angola, implemented online incorporation recently. They're very proud of it, but oh boy, do they need to burn it and salt the earth it stands on. It's harder and takes longer to incorporate online than brave the long lines at the government agency. I can incorporate IRL in 1 day. It took 2.5 months to do it online. Ultimately I gave up and told them to cancel the whole thing. And then it got incorporated the next business day. Maybe I'll also post about that experience.

The free tiers always go away, after they're deep in our infra. I would prefer to price it from the start.

btw sorry for the typos, just re-read this and looks like a dyslexic person wrote it

Have nee dealing with this in an area that requires insane attention: payments. It's strange feeling when you architect a system, all the invariants, all the fundamentals, all the guardrails, then implement the scaffolding in self documenting code, so the LLM has no way to build other than correctly, but you then see what it tries to do and it's WTF.

It all seems to behave correctly and then you run your test suite, and your e2e tests start failing in weirs ways, a few but not many accounting discrepancies, and everything else passes. You spend a lot of time asking it to explain what's happening, you give it the data to browse, and it keeps giving you very plausible explanations of "found the issue, the data shows this clearly, there fore the bug is here, all I need to do is fix this thing", and it does this, and it still fails.

When you open the hood, man, the code salad, the 100s of unnecessary, and complex and duplicate abstractions, the stacked mistakes and lazy corrective attempts, the comment pollution that overrides your instructions across sessions.

You realize that there are things and concepts that it just cannot wrap it's "mind" around and you need to grab the wheel for a bit, make the corrections, remove all the comment litter, commit and then hand the wheel back and tell it to "look at the last commit so see what I mean. explain to me what you did wrong and update all documentation, memory and context with this new understanding".

So if you have no experience in the field, you won't even know how to test, how to find that there is an issue, the appearance of "working" and the AI's confidence will trip you in prod so hard.

This. Depending on your policy or org’s policy, your auth session may be short lived. Going to Google to login and come back every hour is a worse experience. Use your password manager. It will bind the credentials to the domains.

Hands down, the urge of product to assume that codebase is stable and as nimble as a greenfield project, and so any feature can be build with minimal “we just need to make a small change in feature X to do Y”, while never allowing for resources to allow the legacy codebase to keep pace with new features.

The tiniest feature becomes a chess game with unpredictable interactions, not enough tests, etc.

Have you noticed that LLMs leave comments in the code that make it harder for it to self correct? If you notice some unexpected behavior and ask it to explain, it tells you what it did, and if you tell it to implement it differently, even with detailed instructions, it will dive into the code, read its previous incorrect comments and supersede your instructions.

You’ll notice this when you get fed up from going in circles, go peek under the hood and notice it’s been trying to implement your changes while preserving the comments it left before. You’ll even notice it adds to those comments and the code starts creating weird complex branches and abstractions and remains incorrect.

I am now telling it to not leave any comments in the code, but make the code itself be self documenting and clear. No comments.

1. You're probably correct that some statelessness is lost or I'm creating ambiguity. My concept of it is that you don't need to update the token and you don't need to maintain state elsewhere (ie. a list). Rotating the secret simply means you're forgetting how to validate it, you aren't tracking the state of it in your infra with a revocation list. If we go by the script definition, storing an app level secret, so you can validate your issued tokens is also not stateless.

But if we go with that, and downgrade it to somewhat stateless, I think it maintains it's value proposition well, since I have not seen many JWT applications be fully stateless, especially wrt authorization. So I took advantage of that and bolted this so you can use in during your existing authz flow. So pushing to later does not mean let's pull user data later (that does not change the cost). I mean do it when you have the data so you don't have to pull it just for this.

2. Secrets are encrypted at rest, you decrypt them in memory. Of course, if your app encryption key leaks someone can decrypt all those secrets, but this is an attack surface that already exists. Not trying to address that. Also, each user has their own secret, so you have one app level signing key, and N user signing keys, you need to leak all those and then get the app encryption key to decrypt all of them.

"Compared to a stateful session system with split-tokens" - sure, let me just tell every company that is using JWTs to migrate immediately to stateful session tokens. One sec...done, tomorrow will be a better day for all of us :-)

In all seriousness, I posted this a while ago asking for feedback, HN seemed more interested in AI than actual meaningful conversations. I appreciate the feedback and will update the description and make the examples more clear. The intention there was to compress as much as possible and letting readers implement their use of it where it matched their existing setups.

Regarding your link, I took a quick look (saw it a few years ago, forgot about it), but seems I inadvertently built option 6 "Rotate a user scoped signing key lazily, during authz, on pre validated tokens". This is fundamentally different has a new security and usability posture. And it's still not a session token as it keeps all JWT properties that people are using it for (I make no judgement of whether it's the best solution for them, only that they're using it).

Thanks for the feedback, there is room to improve there.

"which we'd likely do anyway for authorization checks". Assuming you are using a session token, authentication != authorization. You will eventually hit your authorization logic to check if the user can perform action X. It may just be through claims in the token, but I don't think most are doing that. So you will eventually pull user data and you can to this check there if you are passing the token through context.

I have been using this for a while, and I haven't managed a revocation list, I haven't done user queries at the boundary and users are able to logout and instantly invalidate their JWT. I honestly haven't seen this elsewhere without overhead.

Maybe I should add a comment there, but this is a compressed example. Everything from getUser onwards does not need to be in the validateToken, it can be done downstream, closer to where you access user data. It does not need to be a separate db call, You pull a user and want to perform an action, so data is in memory, use the secret from there.

Or if you are doing inter service communication, you can use your app secret to validate that the token can actually cross your infra boundary (no user query here), and each internal service can then validate it in their scope, or if a passthrough (like a proxy), just forward it like an envelope.

What this does is give you 2 secure layers, therefore saving you from a lot of the compute (drop expired and globally invalid tokens at the boundary), kill db round trips meant only for token validation (attach to an existing user query you already do) and kill revocation list management.

Even then, AI can still be helpful. My point is if you're going to use it, use it right, and not with the intent to deceive.

A JWT is usually signed, with a secret you keep in your app. The statelessness of JWT is that it contains all the information you need to verify it. You do not need to ask a db if the token is there and valid.

Storing a user's secret, the same way you store your applications secret does not make it more or less stateless.

In since you now have 2 layers of protection, you don't actually need to verify agains a user's secret immediately, you simply need to check that the token is valid using the app secret. The subset of valid tokens that you need to check is much smaller than the universe of all the unexpired tokens your application has issued.

If you have a security incident and need to revoke tokens for only a subset of your users, now you don't need to rotate your app secret and invalidate every single token and break every single session. You can simply log those users out.

Is author's brain stateless -- my bad, I thought this was not reddit

You don't actually have to do a db trip to get a user secret and revoke a token. A token comes in, and you can store the secret in the same place you store your application secret. Because you do need to store it, cache it, whatever. The point here is you no longer need to keep a revocation database of every token you issued that is still unexpired. Just rotate the signing secret and every token issued until then will be revoked. Goes from maintaining millions of tokens to maintaining a smaller cache of user secrets that are probably rarely updated.

Why not an epoch? because this gives control to the user. They can now logout regardless of token ttl. The point is not obsessing over crypto, JWTs are a cryptographic solution, it's what makes them stateless and I have nothing agains cookies or any other session token. I use them interchangeably.

My pain point was that whenever I needed to use a JWT or whenever I worked a company that used JWTs, their main frustration was "oh but then we can't revoke them easily without maintaining a revocation list". Well now they don't have to.

Telling them just migrate to "this or that technology" is not how this works.

Stateless JWT revocation: https://blog.nellcorp.com/new-aproach-to-jwt-revocation/

Still working and looking for feedback on HIP.

Human powered proof of humanity. Nothing on chain, no blockchains. Just DNS / SSL like decentralization. V0 is admittedly less decentralized as a POC (I control the registry and provider), but anyone can implement the protocol and make this truly decentralized.

Registry (even the current one) is meant to be government by multiple independent entities.

Shared before, didn't get much feedback. I've used AI extensively but very thoughtfully. This is very much not vibe coded.

The ecosystem includes 3 apps:

https://humanidentity.io: people signup and get verified here

https://app.humanidentity.io: platforms signup here and manage their oauth

https://protocol.humanidentity.io: documentation, meant to be operated by a governance body

https://platform.humanidentity.io: example platform. You can signup in https://humanidentity.io and then login via oauth here

This is where the absolutism of let agents to 100% of the work fails. You get adversarial agents pulling all reverences into a table, they might miss some, so run this a few times.

Then have another set of agents, with skills like web browsing (to verify that links actually exist, maybe that references and abstracts actually match, etc), have one engineer (or agent) write a small script to help with this (just make sure you test it, and a bit).

So your work is not verified until your references table is 90% green checkmarks, maybe with uncertainty figures.

A human can then verify the ones with under 90% certainty.

This alone gets you a long way there. Does not costs the millions they're being paid.

It's quite interesting that these companies marketed themselves as them best of the best in excellence, accept no mistakes. I can imagine the countless keynotes and books about this. Or the sales pitches.

Has always been a lie, they just understood how to hide it. Today they don't, and it's embarrassing.

So I’m wondering that the end goal and usefulness here is. Is the premise that AI co authored = slop and therefore is bad? And if this succeeds we will start discriminating against co authored code or highly AI co authored code?

As an example, a lot of my new code is AI co authored, but my AI assisted code is probably better than your AI assisted code (subjective I know).

So this could likely add more value if it were scoring quality, architectural soundness, bug/rework ratio, etc. and then you’d be building codescene alternatives.