Hacker News: juberti

New comment by juberti in "GPT‑Live"

juberti — Wed, 08 Jul 2026 17:43:46 +0000

yes, it now has much better ability to understand the conversation and decide whether it should respond (and you can also tell it when it should respond)

New comment by juberti in "200ms Voice LLM"

juberti — Sun, 09 Jun 2024 20:21:59 +0000

We're running it on vLLM and are working with others in the community to bring it to other optimized inference frameworks.

New comment by juberti in "Thefastest.ai"

juberti — Tue, 23 Apr 2024 21:58:29 +0000

We're going to add a selector to choose prompt size (and multimedia content in the prompt)

New comment by juberti in "Thefastest.ai"

juberti — Tue, 23 Apr 2024 21:57:56 +0000

Can you describe what you'd like to see for #1? We currently show everything, but let people filter via the UI or URL param, e.g., https://thefastest.ai/?mf=3-70

New comment by juberti in "Jamsocket: Back Ends for Realtime Apps"

juberti — Wed, 21 Jun 2023 19:43:48 +0000

The basic idea would be a simple voice conferencing bridge that you connect to via WebTransport. There are a number of more interesting things that we would be interested in if we could get this sort of basic scenario working.

New comment by juberti in "Jamsocket: Back Ends for Realtime Apps"

juberti — Wed, 21 Jun 2023 18:42:38 +0000

Do you support WebTransport in addition to WebSockets?

New comment by juberti in "A new way to build with Large Language Models"

juberti — Fri, 10 Feb 2023 07:14:08 +0000

I agree caution is needed here. We have taken a few steps:

- Rate limits are enforced to provide caps on agent and function usage.

- Execution depth is capped to prevent the LLM from getting into loops.

- Function output is sanitized to prevent corruption of LLM state.

- Functions execute in a completely separate environment from the rest of the service, including the LLM, to reduce the impact from bad functions.

Note that this doesn't entirely prevent against "; DROP TABLES"-type hacks against the implementation of the function, but that problem isn't unique to us. It may however be possible for the LLM to look at function inputs and flag overtly malicious ones.

New comment by juberti in "A new way to build with Large Language Models"

juberti — Fri, 10 Feb 2023 03:49:28 +0000

Current context lengths are usually more than adequate for these interactions; the details of each individual step within an execution only need to be retained until the final response is emitted.

New comment by juberti in "A new way to build with Large Language Models"

juberti — Fri, 10 Feb 2023 01:59:18 +0000

It's built-in :-)

New comment by juberti in "A new way to build with Large Language Models"

juberti — Fri, 10 Feb 2023 01:29:35 +0000

yes, the LLM sees the result of the function and processes it according to what it has learned from its few-shots (which may involve calling more functions, or returning a formatted response).

New comment by juberti in "A Study of WebRTC Security"

juberti — Fri, 21 Oct 2016 06:14:03 +0000

Current implementations of WebRTC, by default, only perform STUN over the default route (to address this exact situation).

See https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 for more details.

New comment by juberti in "“We are considering adding an extension to restrict the use of WebRTC”"

juberti — Wed, 29 Jul 2015 01:08:34 +0000

New official Chrome extension to control this: https://goo.gl/74pT1m

New comment by juberti in "Excuse Me Sir, Your WebRTC Is Leaking"

juberti — Thu, 26 Feb 2015 20:52:01 +0000

These ids work just like cookies; scoped to each user and origin. If you clear cookies, the ids are cleared as well.

New comment by juberti in "Excuse Me Sir, Your WebRTC Is Leaking"

juberti — Thu, 26 Feb 2015 20:50:37 +0000

We have added an initial solution for this issue in Chrome 42. Users can set the following preference:

"webrtc": { "multiple_routes_enabled": false },

For the location of the prefs file, see http://www.chromium.org/administrators/configuring-other-pre....

This forces all WebRTC connections to only use server-reflexive and relay ICE candidates, and only on the default IP route. While this may cause a QoS hit (two users behind NAT can no longer keep their traffic internal to the NAT), it does allow the issue mentioned here to be fully addressed without disabling WebRTC altogether.

New comment by juberti in "Status IE – IE's feature status and plans"

juberti — Thu, 03 Apr 2014 01:59:16 +0000

It's OK. You can implement WebRTC as a JS library on top of ORTC.