I found it interesting that (contrary to the popular opinion) there wasn't some magic, e.g. a novel model, happening with Claude Design, especially magic enough that Figma wouldn't be able to replicate if they felt like it.

Also, apparently human (not artificial) neurons were behind that huge prompt, very well aware of the limitations of the model, cheating here and there to make Design's outputs more impressive, making it "create a (design) plan" beforehand, i.e. all the stuff that we the common laymen could do ourselves with the same tools.

Comments URL: https://news.ycombinator.com/item?id=47686777

Points: 3

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=47567572

Points: 5

# Comments: 0

Remote: Yes (12+ years remote experience)

Willing to relocate: No

Technologies: Python, TypeScript/JavaScript, AWS (S3/EC2 Cost Optimization), PostgreSQL (Citus/sharding), C/C++, Temporal.io, Rust.

Résumé/Web: https://valiukas.dev/resume-linas-valiukas.pdf

Email: linas@valiukas.dev

I am a Lead/Staff Backend Engineer with 15+ years of experience. I specialize in reducing cloud costs, scaling large databases, and debugging systems at the syscall level.

Highlights:

* Saved $500k/year at Automattic: reduced S3 storage costs by 75% for a 2 PB dataset.

* 26x Performance Increase: Architected a bespoke binary protocol for WordPress restores, eliminating the #1 product churn reason.

* Scale: Managed a 30 TB+ PostgreSQL cluster (Citus) and NLP pipelines for MIT/Harvard for 10 years.

* Recent Build: Solo-founded https://aero.zip - a privacy-first file transfer service with E2E encryption and OPAQUE authentication.

I debug GnuPG with strace, migrate petabytes without downtime, and replace brittle Cron jobs with robust workflow systems. Looking for complex backend challenges.

Remote: Yes (12+ years remote experience)

Willing to relocate: No

Technologies: Python, TypeScript/JavaScript, AWS (S3/EC2 Cost Optimization), PostgreSQL (Citus/sharding), C/C++, Temporal.io, Rust.

Résumé/Web: https://valiukas.dev/resume-linas-valiukas.pdf

Email: linas@valiukas.dev

I am a Lead/Staff Backend Engineer with 15+ years of experience. I specialize in reducing cloud costs, scaling large databases, and debugging systems at the syscall level.

Highlights:

* Saved $500k/year at Automattic: reduced S3 storage costs by 75% for a 2 PB dataset.

* 26x Performance Increase: Architected a bespoke binary protocol for WordPress restores, eliminating the #1 product churn reason.

* Scale: Managed a 30 TB+ PostgreSQL cluster (Citus) and NLP pipelines for MIT/Harvard for 10 years.

* Recent Build: Solo-founded https://aero.zip - a privacy-first file transfer service with E2E encryption and OPAQUE authentication.

I debug GnuPG with strace, migrate petabytes without downtime, and replace brittle Cron jobs with robust workflow systems. Looking for complex backend challenges.

The goal was to build something as fast as a native app but with the convenience of a web link. Some of the technical bits:

* Instant Streaming: Recipients can start downloading a file the moment the first chunk leaves the sender's computer. No waiting for the full upload to finish.

* Bespoke Chunking Protocol: To handle "unlimited" file counts (tested into the millions), we group small files into larger chunks and split massive files down, so many small files and a few large files can get transferred at similar speeds.

* Auto-Resume: Both uploads and downloads automatically resume from the exact byte where they left off, even if you switch networks or close/reopen your laptop.

* E2EE via Web Crypto API: Everything is AES-GCM-256 encrypted. The secret key stays in the URL fragment (after the #), so it never gets sent to our servers.

* Zero-Knowledge Auth: We use the OPAQUE protocol for logins, meaning we can authenticate users and store their encrypted Data Encryption Keys (DEKs) without ever seeing their password or having the ability to decrypt their files.

* Passkey + PRF: We support the WebAuthn PRF extension. If your passkey supports it (like iCloud Keychain or YubiKeys), you can decrypt your account's metadata without the password.

* On-the-fly Zipping: When a recipient selects multiple files, the browser decrypts and zips them locally in real-time as they stream from our server.

* Performance: Optimized to saturate gigabit connections (up to 250 MB/s) by maintaining persistent streams and minimizing protocol overhead.

Everything is hosted in Germany (EU) for GDPR compliance. I'd love to hear any feedback on the streaming architecture or the OPAQUE implementation!

Comments URL: https://news.ycombinator.com/item?id=46290720

Points: 2

# Comments: 0

Also, aero.zip is a webapp, i.e. there's nothing to install, and you don't even need to sign up to send small files. Meanwhile, croc is a CLI utility which will be hard to use by mom-and-pop users.

https://news.ycombinator.com/item?id=46262540

A few technical details I enjoyed working on:

* Streaming ZIP: To allow downloading multiple files as a single archive without buffering, I implemented a custom streaming ZIP64 archiver. A Service Worker intercepts the request, fetches encrypted chunks, decrypts them, and constructs the ZIP stream on the fly in the browser.

* OPAQUE auth: I used the OPAQUE protocol (via serenity-kit) for the password-authenticated key exchange. It ensures the server never learns the password and protects weak passwords against offline attacks if the DB leaks.

* Passkey PRF auth: If your passkey provider supports PRF (like iCloud Keychain or Windows Hello), the app derives the data encryption key directly from the passkey, allowing a login flow that doesn't require entering a master password.

> I uploaded a file and now I can't download it because the download endpoint is a 404.

Weird, looking at the logs it appears that the service worker didn't manage to register in your browser. Are you using some aggressive adblock by any chance?

I have to resort to registering a service worker and using it for downloads to make the decryption + download as a ZIP work for very large streams. The registered SW then gets added as an iframe, and that iframe triggers the download. In your case, it's as if the SW didn't manage to register so the added iframe led to nowhere.

> Except there is, it's 2GB or 100GB, you said it yourself.

Fair point - my phrasing was poor there. I meant that the architecture has no technical limits (unlike browser-based encryption which often crashes RAM on large files), whereas the 2GB/100GB are just business quotas to keep the lights on.

The architectural difference is actually why I built this. Standard E2EE services often choke on thousands of small files (because they attempt to upload everything with individual HTTP PUTs to S3) or struggle with massive single files (due to memory limits). By streaming encrypted chunks via WebSockets, aero.zip's setup handles 10k 1KB files or one 10GB file with roughly the same performance.

I've created a file sending/sharing website (think WeTransfer) which I believe is unique in several ways:

* End-to-end encrypted * Recipients can start their download anytime, i.e. it's not P2P WebRTC-based thing like FilePizza * (Effectively) no limit on the size of the uploaded data, i.e. it will encrypt/decrypt 100 GB just fine * (Effectively) no limit the number of files that get sent * Real-time transfers, i.e. recipients can start downloading their files even before you finish uploading them * Resumable uploads/downloads * ZIP downloads - creates ZIPs on the fly in the browser from decrypted data * Full passkey auth, i.e. can derive data encryption key from a passkey with PRF * Fast - 10 Gbps link, plus due to the chunking design, uploading 1024 files of 1 KB or a single 1 MB file take about the same amount of time * No nasty trackers

Also, it has a dark mode!

The upload process joins small files together, splits large files apart, builds ~1 MB chunks from the data, encrypts each chunk with AES-256-GCM (each with its own unique IV), and streams it out via a WebSockets channel; the download process does pretty much the same thing in reverse.

Server-side, incoming uploads get written into a bespoke binary format (something like Protobuf) supporting random access. This enables upload/download resume, selective download of one or more files, and real-time downloads.

When downloading, the website sets up a service worker and adds its URL as an iframe (a known hack to force the browser to download something produced by JavaScript). Said service worker fetches the data, decrypts it, and then creates an uncompressed ZIP archive on the fly; for that purpose, I've implemented a whole new streaming ZIP64 archiver (which I'm considering open-sourcing at some point).

I'm using OPAQUE for authentication (though serenity-kit/opaque and Facebook's opaque-ke), as this seemed to be a good way to prevent me from being able to learn anyone's "hunter2" (passwords are used for encrypting the DEK which in turn encrypts uploads' "secret keys" for authenticated users). Also, OPAQUE would prevent weak passwords from getting cracked in case of a security mess-up on my end.

The website is able to authenticate the user fully using just the passkey. If the passkey provider has support for PRF, the website won't have to ask the user for their master password as it will then be able to decrypt the DEK using the PRF; otherwise, passkeys serve as a way to do 2FA. If you'd like to try it out, use iCloud Keychain (on macOS / iOS), Windows Hello, or Android for storing a passkey.

The frontend uses Svelte 5. I'm no frontend magician like some here, but I think at least I managed to keep it fast and simple.

I figured that if our messages are now E2E-encrypted by default, and even which news articles I'm reading on my news website are protected by TLS, then the users of file sending services should enjoy some privacy too - at this point E2EE should be just basic privacy hygiene.

The whole project took way longer than I'd like to admit, mostly because I got nerd-sniped by a bunch of premature optimization, and also had to fake my way into learning how to do modern frontend.

There's a 2 GB free limit for free transfers, also a Premium subscription option with a 100 GB limit. I want this to exist for the long term, but I have to make the finances work. If you find it useful, I'd love your support! If there's interest from HN, happy to share a promo code for a free trial (no CC required).

Feedback welcome!

(Please excuse the grammatical mistakes if any, I'm not a native English speaker, and I didn't want to feed this to an LLM to make it look like AI slop.)

Comments URL: https://news.ycombinator.com/item?id=46262540

Points: 5

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=20881624

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=4056490

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=3557763

Points: 1

# Comments: 0

do you see any possible market for Java Mobile Edition (J2ME) apps as of today?

I mean, everyone's talking iPhone apps, Android apps... But all I can think of is that there are 50%+ Java-supporting phones in any given market. Could there be any business in it?

Comments URL: https://news.ycombinator.com/item?id=1789715

Points: 2

# Comments: 0