jallmann

For interoperability with HTTP tooling (eg, curl) it is the clear winner

My solution to broken connections has actually been to have relatively short timeouts by default, eg 10 seconds. That guarantees we have a fresh connection every so often without any assumptions about liveness. You can even overlap the reconnects a bit (eg 10 second request timeouts, but reconnect every 8 seconds) as long as the application can reconcile duplicated messages - which it should be able to do anyway, for robustness reasons.

Really, anytime there is any form of push (whether SSE, long polling, etc) then you need another way to re-hydrate to the full state. In which case you are nearly at the point of doing plain old polling to sidestep the complexity of server-driven incremental updates and all the state coordination problems that entails.

Of course with polling, you lose responsiveness. For latency-sensitive applications (like an interactive mmorpg!) then HTTP is probably not the correct protocol to use.

It does sound like Second Life has its own special blend of weirdness on top of all that. Condolences to the engineers maintaining their systems.

SSE generally requires the page to be active in the foreground, which is not a viable solution for mobile.

Web Push is a distinct API for browsers to emulate native push notifications via service workers. https://developer.mozilla.org/en-US/docs/Web/API/Push_API

All that speaks to the point that the underlying protocol does not matter that much. The larger design is a more important consideration than the specific push tech.

None of this favors SSE, or anything else for that matter. You still have to think about bursting / thundering herd behavior after server restarts, which would affect any protocol. The browser auto reconnecting doesn't mean you can assume the connection remains alive indefinitely if a reconnect hasn't happened; you may want periodic notifications as a keepalive to enable more immediate recovery. Long-lived server state introduces its own distributed coordination and cleanup problems, which strict request-reply polling sidesteps entirely. Etc.

There is no silver bullet, only tradeoffs in the design space that need to be matched to your application's requirements.

Yeah that is a great article, and I agree that long polling an events endpoint along with a cursor gets you most of the way there for browser clients. At that point, things start to resemble the Kafka protocol.

Browser push APIs are hard to design well regardless of the underlying protocol (SSE, Long Polling, Websockets, etc). There are a bunch of things to consider:

- Is this a full or partial state update?

- What if the client misses an update?

- What if the client loses connectivity?

- How can the server detect and clean up clients that have disappeared?

How those are answered in turn raise more questions.

SSE or long polling or even WebSockets is a relatively unimportant implementation detail. IMO the bigger consideration should probably be ease-of-use and tooling interoperability. For that, I would say that long polling (or even just polling) is the clear winner.

Long polling is more amenable than SSE for most HTTP tools out of the box, eg curl. The SSE message body is notably different from plain HTTP responses.

To the OP, you can still build APIs with long polling. They are uncommon because push patterns are difficult to design well, regardless of protocol (whether long-polling, SSE, websockets, etc).

Whiteboarding a push API is a good exercise. There is a lot of nuance that gets overlooked in discussions whenever these patterns come up.

How does this compare to hsnwlib - is it faster? https://github.com/nmslib/hnswlib

Nice. I have something similar at https://analyzer.transfix.ai which is a searchable index of many of the images + prompts that have been featured as part of the Midjourney community showcase.

Very under-documented at the moment, but it's been pretty neat explore what the community comes up with, learning prompting techniques and spotting trends (eg, a surge of Christmas images around October), for isolating the effects of specific parameters, and other narrow latent space exploration.

I was also thinking of opening it up for teams to collate their stuff into a single searchable data set (eg, all my prompts are at https://analyzer.transfix.ai/?db=josh ) but have moved away from doing anything with Midjourney because they are pretty hostile to anyone playing outside their sandbox.

Open source is really about reproducibility. Most of these model releases are better described as "open weights" because we don't know how exactly they were trained.

Google Chrome [1] also has captioning built-in [2], so this could also work from a plain page that hooks into the loopback device. Pretty sure it's using the same TTS backend that Google Meet uses.

The nice thing about Chrome feature is you can move the caption box around and keep it in the foreground while doing other things, although styling options seem limited (the text might be a little small for some).

[1] on desktop, not sure about mobile

[2] via chrome://settings/accessibility -> Live Caption

When WebRTC was being developed, a lot of the underlying protocols were derived from existing standards (RTP, SDP, etc), ostensibly with the intent of making it easier to bridge to legacy video-conference systems that may have been running SIP or similar.

Beyond that, there is a ton of stuff to accommodate different device capabilities, network conditions, realities of the Internet, etc. WebRTC has tried to be a "nice thing" for developers from an API perspective for the use-case of streaming realtime video to the browser, but of course all those knobs under the hood make it seem like a hodgepodge, rightly or not.

Would a clean-slate design with more tightly scoped goals fare better? Probably. But the underlying complexity needs to be handled somewhere and there are always trade-offs between control and ease-of-use.

Very interesting that ChatGPT seems to prompt Dall-E via the client, rather than keeping that interaction entirely server-side. Keeping it server-side would be less likely to leak details as seen here, and makes it less susceptible to tampering.

Also nice to see that Dall-E 3 seeds were finally fixed. That must have happened within the last week or so; they weren't working last I checked (chatgpt always used a fixed seed of 5000).

> Midjourney and Stable Diffusion both have a “seed” concept, but as far as I know they don’t have anything like this capability to maintain consistency between images given the same seed and a slightly altered prompt.

I suspect this is more a function of Midjourney's prompt adherence being fairly poor right now. Even so, the images often aren't dramatically different. Example:

https://analyzer.transfix.ai/?db=josh&q=%28robot+%7C%7C+andr...

Exactly - content authenticity is a narrower and more tractable problem.

And I suspect in most cases that is enough - the world runs on trust, so if a reliable source (eg, the NY Times) attests that a photograph is authentic, then we can reasonably trust that. And as you noted, this chain of provenance can go all the way back to the device itself.

Fraud, on the other hand, is much harder to prove without a doubt. It is still a problem, but probably less so in the general case [1]. The concerning thing seems to be extremely targeted attacks, eg, hacking a CCTV to implicate someone in a crime.

[1] Notwithstanding folks who slurp up unfiltered content on, eg, TikTok, but the most outrageous stuff usually doesn't "make the news" on its own without more vetting. If anything, this will reinforce the importance of actual journalism, fact-checking and corroborating evidence.

Agreed that cryptographic provenance seems like the best way forward, however the goal is more about proving authenticity, less about detecting fraud. Small but important distinction.

There are industry initiatives around this already such as CAI https://en.m.wikipedia.org/wiki/Content_Authenticity_Initiat...

For a stylized history of the early industry: The Tinkerings of Robert Noyce, by Tom Wolfe https://web.stanford.edu/class/e145/2007_fall/materials/noyc...

I also read "A History of Silicon Valley" back in college (~2010) and really enjoyed it; looks like it's been updated continuously since then: https://www.scaruffi.com/svhistory/sv.html

I use Deno because I couldn't be bothered to figure out the Node ecosystem and how to actually wire together the Typescript compiler, package json, builders and bundlers, etc. I just do not care and the mess of tooling is frankly exhausting to wade through.

Deno Just Works for me. `deno run file.ts` and you are good to go.

Not to say it's been 100% smooth sailing; I have hit a few rough patches with deployment into my own infrastructure (some within Deno and its dependency management, some within libs like sqlite3) but overall I am happy to not deal with nodejs.

This is good news. Retool-local storage was a big missing piece of the puzzle for us.

For self-hosted customers, is the database still on-premises? Or does it live in the Retool cloud?

Try one of the sign languages. Not sure where you are located, but many countries have their own, including India.

This was a great article. While I was at Livepeer (distributed video transcoding on Ethereum [1]), we converged onto a very similar architecture, disaggregating scheduling into the client itself.

The key piece is to have a registry [2] with a (somewhat) up-to-date view of worker resources. This could actually be a completely static list that gets refreshed once in a while. Whenever a client has a new job, they can look at their latest copy of the registry, select workers that seem suitable, submit jobs to workers directly, handle re-tries, etc.

One neat thing about this "direct-to-worker" architecture is that it allows for backpressure from the workers themselves. Workers can respond to a shifting load profile almost instantaneously without having to centrally deallocate resources, or wait for healthchecks to pick up the latest state. Workers can tell incoming jobs, "hey sorry but I'm busy atm" and the client will try elsewhere.

This also allows for rich worker selection strategies on the client itself; eg it can preemptively request the same job on multiple workers, keep the first one that is accepted, and cancel the rest, or favor workers that respond fastest, and so forth.

[1] We were more of a "decentralized job queue" than "distributed VM scheduler" with the corresponding differences, eg shorter-lived jobs with fluctuating load profiles and our clients could be thicker. But many of the core ideas are shared, even our workers were called "orchestrators" which in turn could use similar ideas to manage jobs on GPUs attached to it... schedulers all the way down!

[2] Here the registry seems to be constructed via the Corrosion gossip protocol; we used the blockchain with regular healthcheck probes.

Usko Privacy | Miami, San Diego, REMOTE | Software Engineer ($120k)

Usko Privacy allows people to analyze, manage and monetize their personal data. We have Android and iOS apps showing analytics of your Amazon purchase history - all your data stays private, on your device. We are looking for help in executing the next parts of our roadmap.

https://uskoprivacy.com

This would be an opportunity to get in on the ground floor and leave your imprint on an early-stage, venture-funded company headed by experienced entrepreneurs and technologists.

We are looking for a generalist who can both write application code, and contribute to the operational aspects of our systems. The focus is mostly on the backend and related ops tooling, but the ideal candidate would be comfortable picking up front-end work where needed. Our stack is primarily made up of Node / Typescript and PostgreSQL, with [prod, staging, test, CI] infrastructure running on Linode + Docker Compose, wired together with Github Actions. Prometheus for metrics, Retool for internal dashboards, the works.

Candidates should be generally available during US East working hours. The interview process is:

1. Intro call

2. Choice of take-home coding exercise + call to discuss the exercise, or a live coding screen

3. Founder call

Some press around our recent launch: https://refreshmiami.com/furthering-data-privacy-mission-mik...

Contact josh@usko.app with the subject "HN: Software Engineer" along with a resume / LinkedIn

Not sure if Mastodon supports this, but the account could belong to one instance while being verified by another. This also lets folks be verified by multiple organizations - which also increases trust.

Thanks for the feedback - it would be a full time position. I know the salary is on the low end, but we're also comfortable taking in and mentoring someone early in their careers (eg, boot camp grads). The expectations might be high, but they would not be working in a vacuum; we have a great team that is able to provide support and guidance to help them succeed.

Usko Privacy | Miami, San Diego, REMOTE | Backend and Ops Engineer ($120k), UX Designer ($65k)

Usko Privacy allows people to analyze, manage and monetize their personal data. We have Android and iOS apps showing analytics of your Amazon purchase history - all your data stays private, on your device. We are looking for help in executing the next parts of our roadmap.

https://uskoprivacy.com

This would be an opportunity to get in on the ground floor and leave your imprint on an early-stage, venture-funded company headed by experienced entrepreneurs and technologists.

For the backend role, we are looking for a generalist who can both write application code, and contribute to the operational aspects of our systems. Our stack is primarily made up of Node / Typescript and PostgreSQL on the backend, with [prod, staging, test, CI] infrastructure running on Linode + Docker Compose, wired together with Github Actions. Prometheus for metrics, Retool for internal dashboards, the works.

For the UX role, we are looking for someone who can work with our product team to tell the Usko story through our apps, and collaborate with the development team to bring that vision alive. Responsibilities would include user interviews and surveys, best-practices UX research, building lo-fi and hi-fi mockups in a Figma-like tool.

Some press around our recent launch: https://refreshmiami.com/furthering-data-privacy-mission-mik...

Contact josh@usko.app with the subject "HN: <role>" along with a resume / LinkedIn or portfolio link

It is a layering violation though. Not all HTTP usage is through a browser, and not all routes go over the plaintext Internet. Browsers or clients can still require HTTPS at the application layer, but it shouldn't be part of the protocol spec.

Suppose I have an app within an intranet that's secured with, say, Wireguard or an application-layer tunnel (eg, SSH or Openziti).

Bringing HTTP/3 into the picture means dealing with CAs and certs on top of the provisioning I've already done for my lower layers, possibly leaking information via Certificate Transparency logs. Then the cost of double-encryption, etc.

Golang has panic / recover / defer which are functionally similar to exceptions. It's actually a fun exercise to implement a pseudo-syntax for try/catch/finally in terms of those primitives.

Also issue with golang (+ protobufs) where you can't distinguish a populated zero value from the default "not present" value.

This article is also a good explainer for Tiger's high-velocity capital deployment strategy - https://randle.substack.com/p/playing-different-games

Great writeup of some of the design thinking and challenges around building a ZK system.

Using a community chest to reward front-runners for submitting claims is clever. Would the ETH reward still need to be at least as large as the transaction cost to incentivize front-runners? Or is there still a cut of the token being taken, in the hopes the token value will make up the difference?

It seems like there would still be a basic gas problem any time the receiving account wants to use the (ERC-20) token, eg to send the token somewhere else via a wallet or some other standard UI?

Very useful exercise, thanks for sharing.

For Robinhood crypto, there's form8949.com which is generally fantastic. It can import from a number of crypto exchanges in addition to the traditional brokers.