filearts

I think it is against the spirit of this community to suppress exciting content on the basis of its language.

This community is also undoubtedly composed of the kind of problem solver that can overcome this kind of hurdle.

My oh shit moment was when tool calling was emerging as a capability. That was the moment I realized that LLMs would be the glue connecting a million different use-cases in a million ways we wouldn't even be able to imagine.

Lot's of comments are nit-picking on how this demo misses the mark on specific technicalities of domains they're familiar with.

But that's totally missing the point: this is a demo of what seems like a totally new interaction model that could not previously have existed. It's a small glimpse at a possible future where those nit-picky details get better.

Remember when image models produced grotesque hands? Now look at GPT Image 2 and Nano Banana Pro; those original nits are mostly a thing of the past.

Take a look at this not for its immediate flaws but for the new doors it opens and the expansion of our collective imagination.

Is it really AI slop if someone leverages AI to improve / transform their novel experiences and ideas into a rendition that they prefer?

I'm not suggesting whether or not the article is AI assisted. I'm wondering if the ease of calling someone's work "AI slop" is a step along the slippery slope towards trivializing this sort of drive-by hostility that can be toxic in a community.

Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.

I think it is distasteful and disrespectful to call out an employee by name in this way, regardless of the merit of the rest of the OP's post.

That's a bit of a naive perspective. There are plenty of situations and industries where access being down has an impact far beyond inconvenience. For example, access to medical files for treatment, allergies and surgery. Or access to financial services.

This is the interface I landed on to make pluggable 'session hosts': https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad...

It goes a tad beyond the spec minimum because I think it's valuable to be able to persist some small KV data with sessions and users.

What I've started experimenting with and will continue to explore is to have project-specific MCP tools.

I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts.

So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent.

It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.

In a previous professional life, I did financial modelling for a big 4 accounting firm. We had tooling that allowed us to visualize contiguous ranges of identical formulas (if you convert formulas to R1C1 addressing, similar formulas have the same representation). This allowed for overrides to stick out like a sore thumb.

I suspect similar tools could be made for Claude and other LLMs except that it wouldn't be plagued by the mind-numbing tedium of doing this sort of audit.

An idea might be to require a financially meaningful deposit to pursue an account recovery like this. The deposit would be forfeit if the identity verification failed.

Though now that I write this, it creates a perverse incentive for a company to collect deposits and deny account recovery.

It is fascinating how similar the prompt construction was to a phishing campaign in terms of characteristics.

  - Authority assertion
  - False urgency
  - Technical legitimacy
  - Security theater

As is often the case, reality imitates satire. This reminds me of the "and then" scene from Dude, Where's my Car. https://youtu.be/iuDML4ADIvk

If you were willing to bring additional zod tooling or move to something like TypeBox (https://github.com/sinclairzx81/typebox), the json schema would be a direct derivation of the tools' input schemas in code.

I took a stab at this a while back using an object to represent the possible resolutions. The keys of the object become a signal upon resolution that indicates which branch fired. https://github.com/ggoodman/channels#select-key-string-chann...

Ultimately though, I don't believe that channels are an abstraction that makes sense in JavaScript's concurrency model. Go's contexts, on the other hand, would be a huge improvement over AbortController and AbortSignal.

Software engineers don't want to be managing physical hardware and often need to run highly available services. When a team lacks the skill, geographic presence or bandwidth to manage physical servers but needs to deliver a highly-available service, I think the cloud offers legitimate improvements in operations with downsides such as increased cost and decreased performance per unit of cost.

Seems like a fair trade-off to make.

Not anymore. The busses only come every 5m90s on that route.

Misallocated and misappropriated are two very different things. The linked tweet makes no mention of misappropriation.

I would love to see an image like that combined with a depth map to allow us to move it around and get a sense of the vertical scale of those storms!

This service appears to have launched a new (to me) UX based on React instead of AngularJS, like the rest of the console. I'm certainly enjoying the new design elements.

I think that the author means that yarn is a client for the npm registry. It doesn't at all sound ridiculous when stated that way.

We built Auth0 Extend [1] to address with many of these concerns. Our hypothesis is that the logic that implements these extensibility points should live in the host platform.

For several years now, we've had this sort of hook-via-code in the Rules engine on our Auth0 identity product. It's been such a powerful enabler for many different integration scenarios that we thought that other companies may find the technology useful for their platforms.

Since committing to building Auth0 Extend, we've seen Twilio launch their functions [2] and just today CloudFlare launched its Workers [3]. It seems like the this is an approach that is in its infancy but that is here to stay!

1: https://auth0.com/extend/developers

2: https://www.twilio.com/docs/api/runtime/functions

3: https://blog.cloudflare.com/introducing-cloudflare-workers/

Creator of https://plnkr.co here. Amazing work on StackBlitz. Looking forward to figuring out how it all hangs together. Very novel approach indeed.

Anecdotally, I was the one who contributed ?json support to unpkg for a related use-case (in browser editor). OSS at its best, moving everyone forward. I use use the feature to provide a similar (but more limited) package injection. Check out https://next.plnkr.co/edit/ (book icon in toolbar of html panes) to see it in action.

@mmalone: Auth0 Extend uses the Webtask technology stack we created at Auth0 that has run our Rules pipeline for over 3 years.

Your questions are spot on: isolation is really the selling point of Auth0 Extend. When running your customers' code on their behalf, a platform needs to be absolutely sure that each customer's runtime environment is isolated from all others. We provide the concept of 'named containers'. These containers represent isolation boundaries. On a PaaS, each tenant of that platform might be assigned a container or each project may be assigned a container. The level at which isolation guarantees are delivered is really up to the platform implementing Auth0 Extend.

Another feature that distinguishes Extend from other 'Serverless' offerings is the absence of material cold latency. Because we use Extend at Auth0 to provide extensibility for the user authentication pipeline, minimal latency is and has always has been a requirement.

It is a very hard (if not impossible in a generic language like Javascript) to _prevent_ code from doing dangerous things. This is not something we pretend to do. Instead, we provide isolation so that the only tenant affected by bad code is that tenant. To minimize the impact of bad code, we have great tooling like real-time streaming logs to facilitate debugging.

Hope this answers some of your questions. If not, join us on Slack: https://auth0-extend.run.webtask.io/slack-signup

The Webtask technology is closed-source. Much of the tooling, however is open-source.

The programming model exposed by a SaaS implementing Auth0 Extend is totally customizable by middleware. If you feel that your users would be more familiar with a Promise-based model, this can easily be provided.

See: https://github.com/auth0/extend/wiki/Auth0-Extend-User's-Gui...

You might have seen Graphcool's launch yesterday where they announced 'inline functions'. Graphcool is running its users' code on their behalf right in the hot code path of their mutation pipeline. This means they're able to run untrusted code in an isolated and low-latency manner and at scale.

You may have seen something similar before in Auth0 Rules [1]. That the two share similarities is no coincidence! Auth0 Rules and Graphcool's 'inline functions' use the same Webtask technology behind the scenes.

We packaged up this technology to provide the first and only 'Extensibility as a Service' offering called Auth0 Extend [2]. Auth0 Extend builds on the familiar webhook model but removes the friction webhooks impose on user; no more standing up and managing servers just to handle webhook invocations. Auth0 Extend makes it trivial to transform a platform's webhook integration into an in-platform custom code editing experience.

1: https://auth0.com/docs/rules 2: https://auth0.com/extend

You might also find the following blog post provides a useful introduction: https://auth0.com/blog/introducing-auth0-extend-the-new-way-...

I think that the request pipeline is interesting enough to warrant a little discussion. Graphcool is running its users' code on their behalf right in the hot code path of their mutation pipeline. This means they're able to run untrusted code in an isolated and low-latency manner.

You may have seen something similar before in Auth0 Rules [1]. That the two share similarities is no coincidence! Auth0 Rules and Graphcool's 'inline functions' use the same Webtask technology behind the scenes.

At Auth0, we're working on packaging up this technology to provide an Extensibility as a Service offering called Auth0 Extend [2]. Auth0 Extend builds on the familiar webhook model but removes the friction webhooks impose on user; no more standing up and managing servers just to handle webhook invocations. Auth0 Extend makes it trivial to transform a platform's webhook integration into an in-platform custom code editing experience.

Look for more details Auth0 Extend in the coming days as we make our public launch. Also look for other exciting imminent product launches from our integration partners.

Congratulations on a beautiful and functional product launch Graphcool!

1: https://auth0.com/docs/rules

2: https://auth0.com/extend

To the extent that you are pulling new stories directly from Firebase on the client side, encrypting (or signing) urls with a symmetric key will not work. This is because you would need to embed the secret in the front-end code which means the secret is no longer secret ;-)

You could also tail the Firebase feed from a server process, generate the relevant images and only serve images for pre-existing urls.