iafan

I understand the core is the layout engine and a component library? Does the rendering somehow benefit from GPU?

I recently had a good experience creating custom UI based on ebitengine — also a cross-platform Go engine. As it is a game engine, it has this built in game drawing loop, GPU-accelerated, with some cross-platform kb/mouse input handling. And this feels like a good platform to build the layout engine and components on top of. Have you ever considered this? Or how does your approach compare to that of ebitengine? Did you try (and do you position) your library to build custom UI for some underpowered computers such as Raspberry Pi?

Some time ago I created a proof-of-concept reverse CAPTCHA[1] that actually presents a challenge that requires LLM assistance to solve, alongside with the instructions. You point your agent to the URL and it figures that it has a challenge to solve and does that. Seems more in spirit of what a CAPTCHA-like test for AI agents should do.

[1] https://github.com/iafan/botcha

One may still write C code as they did 40 years ago, but they still use the power of numerous libraries, better compilers, Git, IDEs with syntax highlighting and so on. The only true difference — to me — is the speed of change that makes it so pronounced and unsettling.

It makes me sad to read posts like this. If it is a necessary step for you on the journey from denial to acceptance to embracing the new state of the world, then sure, take your time.

But software engineering is the only industry that is built on the notion of rapid change, constant learning, and bootstrapping ourselves to new levels of abstraction so that we don't repeat ourselves and make each next step even more powerful.

Just yesterday we were pair programming with a talented junior AI developer. Today we are treating them as senior ones and can work with several in parallel. Very soon your job will not be pair programming and peer reviewing at all, but teaching a team of specialized coworkers to work on your project. In a year or two we will be assembling factories of such agents that will handle the process from taking your requirements to delivering and maintaining complex software. Our jobs are going to change many more times and much more often than ever.

And yet there will still be people finding solace in hand-crafting their tools, or finding novel algorithms, or adding the creativity aspect into the work of their digital development teams. Like people lovingly restoring their old cars in their garage just for the sake of the process itself.

And everything will be just fine.

Everything that is touching hardware, for example. Bluetooth stack, HDMI, you name it.

Everything W3C does. Go is evolving through specs first. Probably every other programming language these days.

People already do that for humankind-scale projects where there have to be multiple implementations that can talk to each other. Iteration is inevitable for anything that gains traction, but it still can be iteration on specs first rather than on code.

If I had a spec for something non-trivial, I probably would ask AI to create a test suite first. Or port tests from an existing system since each test is typically orders of magnitude easier to rewrite in any language, and then run AI in a loop until the tests pass.

There are two main schools of thought in software development about how to build really big, complicated stuff.

The most prevalent one, these days, is that you gradually evolve the complexity over time. You start small and keep adding to it.

The other school is that you lay out a huge specification that would fully work through all of the complexity in advance, then build it.

I think AI will drive an interesting shift in how people build software. We'll see a move toward creating and iterating on specifications rather than implementations themselves.

In a sense, a specification is the most compact definition of your software possible. The knowledge density per "line" is much higher than in any programming language. This makes specifications easier to read, reason about, and iterate on—whether with AI or with peers.

I can imagine open source projects that will revolve entirely around specifications, not implementations. These specs could be discussed, with people contributing thoughts instead of pull requests. The more articulated the idea, the higher its chance of being "merged" into the working specification. For maintainers, reviewing "idea merge requests" and discussing them with AI assistants before updating the spec would be easier than reviewing code.

Specifications could be versioned just like software implementations, with running versions and stable releases. They could include addendums listing platform-specific caveats or library recommendations. With a good spec, developers could build their own tools in any language. One would be able to get a new version of the spec, diff it with the current one and ask AI to implement the difference or discuss what is needed for you personally and what is not. Similarly, It would be easier to "patch" the specification with your own requirements than to modify ready-made software.

Interesting times.

On iPhone, tapping an NFC tag with a URL opens a popup that allows you to navigate to that URL with a single click. If this URL is supported by an installed app, this app will handle this. For example, if you write a URL of a Spotify playlist onto your NFC tag/sticker (which you can also do from the phone via an app like NFC Tools), then bring that sticker to iPhone, it will show this as a Spotify URL, and you can tap on this notification and go to that Spotify playlist. So all you need to experiment with is a writable NFC tag and your phone, no other hardware required. I bet Android phones offer a similar experience.

Active noise cancellation headphones (without playing music). Bought ones recently and can't be happier. Works both in office and when working from home, and are great in cancelling the background noise (like HVAC) and lowering the overall volume of speech to the extent it doesn't bother.

I do, however, usually combine noise cancellation with a — now pretty quiet — background electronic music with no voice, which I've found helps me concentrate.

BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.

I believe that it'd better be explicit (like in OAuth, where the web service asks for a permission to access your email) and optional (defaulting to not asking for email).

Note that services usually don't need emails (at least not right away). They should also continue working just fine if the user decides not to provide their email initially — the service may ask for user's email at a later step. I also see that the similar concept might be used to ask people for or other sensitive data, like delivery/billing address and payment info; this way I as a service developer don't have to store anything on the web service at all except for the unique user token, and the user would be able to provide this information with a single click as well — same as in your demo app where the user confirms a transaction.

Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.

I'd probably disagree here. Installing an extension is much faster/easier than a native app; it can store data in localStorage (so no centralized service is needed), it can solve your Safari-related discoverability issues, and it can provide a really nice UX for web-based service authentication with no context switching between apps. I'm not a security expert, but a browser extension storing your data locally should — theoretically — be as secure as a native app. Am I missing something here?

Would love to continue the discussion offline. Is it ok to email you?

Yeah, I'm an every-day-user of enterprise Duo app. It is as good as a third-party app can be (on iOS specifically), yet you have to do extra steps as compared to Touch ID alone: force-press the notification, click Accept, then confirm with Touch ID. The first steps out of two are just a limitation of how apps work in iOS. If your phone is in sleep mode, you will miss the notification as well. Such things really need to be implemented on OS level.

But apart from arguably good iOS app UI, it takes the whole IT department to enable Duo 2FA and educate employees on how to enable and use it on their personal accounts, and that's what I don't like about Duo and other solutions. Also, this is just a second step of the two-factor auth, which means the first step (usually plain old username/password auth) is still there.

In my ideal world, I'd prefer something that worked out of the box (with very easy bootstrapping process). I believe SecureLogin, as a concept, has potential here, and if implemented right, might lead to some standardization and implementation of more transparent 1FA/2FA flows.

This is a very interesting concept. I'm pretty sensitive to UX issues, and I'm yet to see nicely implemented and secure auth flows. All non-OS-native 2FA solutions (Google Auth, Duo) seem a bit cumbersome (and require additional efforts to implement and to setup for the average user). Apple does auth right with their Touch ID (both for logging in and to confirm transactions). I see a potential for SecureLogin to be as close to that Touch ID user experience as possible.

While I see the potential, I understand that this is an initial implementation, so it has UX issues:

1. First and foremost, the user has to download an app in order to sign into your service. That's a huge ask. Service providers will be hesitant to implement this, since this will mean losing customers. The implementation has to be really polished for this to gain traction, IMO. Without getting initial traction, it's less likely that this can be implemented natively in browsers/OS, where this technology makes more sense and can have better UX. Kind of a catch 22.

2. Related to 1: A 50+MB Electron app is definitely not a casual download. It has to be as lightweight and OS-native as possible. For most likely use case (web app authentication), did you consider using browser extension that would store the data locally? Might be a good alternative to a downloadable app at least for that common use case.

3. When signing in, it asks if one has the app installed. I don't want to be asked. If the app is not there, I want to have it installed in one click, and then have the auth retried. And visiting a separate https://securelogin.pw/ site for downloads is not the best option as well. This bootstrapping process is very important. Again, a browser extension might help with this, since it can communicate with the page and make itself discoverable.

4. As I understand, Cobased is your reference demo app. As such, it needs more polishing/explanation (read: some narrative in addition to the UI).

---

And a non UX-related question: nowadays people not only value security, but anonymity as well. Does SecureLogin have to pass profile email address back to the app? Can the protocol work in the way that simply uniquely identifies the user for the target service via providing some service-unique token but not disclosing an email address? In other words, the protocol might benefit from the fact that no one can link account on service A to the account on service B.

Thanks for sharing. This proposal makes every bit of sense, IMO. I wish selection sharing could also be a part of some cross-browser standard so that people wouldn't have to install anything on their sites. It's one of the things that would just work if it was implemented universally across major browsers.

I know that the best available option in today's world is to make a screenshot of a selection to point to a specific point on a page, but heck, this seems to be an extreme waste of bytes when the only thing you want to do is to point someone to a specific word or a phrase...

The closest implementation that comes to my mind is GitHub's ability to select a line or a range of lines that would immediately update the hash and give you a permalink to the selection, e.g.: https://github.com/iafan/LinkToSelection/blob/master/lib/Lin... , and I think this is one of the small but handy features people love GitHub for, but it has a very specific use case and doesn't allow one to point to a range in the string, or just one character that, for example, is causing a problem.