ftlio
Joined 10 years ago
Joined 10 years ago
Unless you’re operating in an anonymity preserving space, you can just do this and choose to integrate with passkey later.
The main disadvantage of this method is that you have to think about managing multiple users for an account sooner than you normally would, since sharing a password is no longer possible. I can’t think of a funnel or UX that isn’t ultimately improved by conscious effort here.
The other is of course that your security becomes limited by the weighted average of security of your users’ email providers, which will generally be better than you need. Passwords can then be your second factor here, when you finally need them, or you can use some other factor yet again. In B2B you can jump straight to SAML or OIDC connections.
In B2B or D2C contexts this has always just worked and the edge cases are generally worth solving for the benefits to acquisition.
Hard agree.
> Maybe this all changes when AI takes over, but AI seems to do fine without us defining ontologies, etc.
I think about it as:
- Hypermedia controls were been deemphasized, leading to a ton of workarounds to REST
- REST is a perfectly suitable interface for AI Agents, especially to audit for governance
- AI is well suited to the task of mapping the web as it exists today to REST
- AI is well suited to mapping this layout ontologically
The semantic web is less interesting than what is traversable and actionable via REST, which may expose some higher level, reusable structures.
The first thing I can think of is `User` as a PKI type structure that allows us to build things that are more actionable for agents while still allowing humans to grok what they're authorized to.
My startups perspective: I think it’s hard for people to understand the subtlety from all the memes and hearsay.
We hear that you need to talk to your users to understand what to build, but I’ve seen this fall flat on its face and lead to extreme confusion, several times now, when you’re not talking to your users as a matter of observing your product/business model against reality to then update the axiomatic thinking that (hopefully) lead you to its current iteration.
I’ve seen this play out as a cringy ask to “let us know if you think of any other features you might like” met with puckered faces from customers that essentially said “or how about not because my job isn’t to build your product?”
This is Henry Ford / Steve Jobs talking about faster horses. You’re not asking your customers what to build. You’re asking them to help you understand the reality against which your logic plays.
Then there’s the opposite, where a business marches forward because some axiomatic thinking has determined that the macro environment should support it, not updating itself against a pending catastrophe in cash flows that leads to cuts that further undermine its ability to exist even within its own framework.
Design and test from first principles, but operate for the pain of as many rounds as possible. Maybe one day you can truly optimize and it won’t hurt as much.
BTC is liquid enough while seeing billions of dollars in inflows a month to discount wash trading as a major factor.
If you asked me to assemble 10 different sandwiches, and 1 antipasto salad, some of which I'm seeing for the firs time, I would attempt to gather all the ingredients, but ultimately end up going back and forth between the cupboard and refrigerator still. I might even think, on one of those trips, hey, I don't need the mayo anymore, so I can put it away, only to have to go back and get it again for a later sandwich. The end result would probably be all the ingredients for every sandwich on the counter at the same time, as I should have done.
I'm pretty smart though. I'm good at Abstraction. So, I assume I'm going to get another order from the family for a sizable amount of sandwiches and some more antipasto salad. I name each sandwich and salad type and then write down a list of ingredients for each sandwich so I can cross-reference it to assemble a master list of all required ingredients per sandwich when the next order comes in. I can then go to the cupboard and refrigerator once.
I then order each sandwich type by their shared ingredients, so that I can apply ingredients only once until I'm done with that ingredient (and then I could put it away, but I'm not a premature optimizer). The only issue is that some ingredients require slicing, like tomatoes, and tomatoes aren't sliced in the same manner for the salad as the sandwiches, and my daughter can't stand when the tomatoes and lettuce touch on her sandwich, and my other daughter wants the cheese and the meat separate. I don't want to overcomplicate the problem, but I don't want to Repeat Myself either, since I know I can grab the tomatoes and slice them all up in the same step, so I need to remember when I assemble my list of ingredients per sandwich and salad that some are exempt from the ordered application of ingredients and must be handled by a single, separate script for assembly.
I run this process a few times, and it works, but I learn that it takes me 35 minutes to do, and that there's now a hard requirement on a frozen item involved with one of the sandwiches that it not be out for more than 10 minutes, so now this ingredient itself must be exempted from the step where I grab all ingredients and my assembly instructions for the one sandwich that involves this ingredient must be very clear that I will still also need to grab that ingredient.
Then I learn/realize:
In-fact, 90% of the time I make a sandwich, or salad, I only make one at a time.
OR
Nobody wants to order sandwiches by name, they just want to give me a list of ingredients in the right order
OR
I am gradually making so many more sandwiches every day that my kitchen counterspace cannot support getting all the ingredients at once
OR
I only make the same sandwiches + one salad every day to the exact same specification
When life hands you executives with zero accountability, make lemonade I suppose.
That glut of new money took a flight to quality in banks and things like tech companies. Such firms, and all the people that contract with them or are employed by them as downstream from this money thus had a warped cost to capital compared to everyone else.
It wouldn’t make sense to operate a business and not choose the customer who can support a higher price point over the lower one with an identical cost, and with such a large delta, increasing margin as a matter of price increase made fundamentally more sense than investing in cost reductions.
The fact is that Central Banks had the largest role to play here assuming that choosing to make more money over less money by simply raising prices is not inherently evil.
“Nobody likes my product because they are stupid”.