HN user

rfonseca

92 karma

[ my public key: https://keybase.io/rodrigo_fonseca; my proof: https://keybase.io/rodrigo_fonseca/sigs/hFBIpA9QIo9TNn4-DLeYLY1nlpyv5dm45dbQCGOd35g ]

Posts3
Comments34
View on HN

I was part of the early alpha for this, they opened a beta wait list today. The thing that is different here is that they remove 99.9% of the friction to create agents, the target user group is not a user who can run Claude Code and install their app on some service, it is everyone else who couldn't be bothered to worry about plans, keys, domain names, datatabes, etc.

You talk to a master agent (Sidekick) describing the app you want, and it creates it for you, batteries included (a lot of tools, which are vetted MCP servers and skills, a database, cron-jobs, and a hosting environment where your apps live). The tools connect to many things such as email, slack, weather, sports, news, web, and your agents can do all sorts of things.

(disclaimer: I work at Microsoft, but am not directly involved with Durable Functions)

Being a library is a pretty interesting feature! Correct, Durable Functions allows you to write task-parallel orchestrations of task-parallel 'activities' (which are stateless functions), and these orchestrations are fully persistent and resilient, like DBOS executions. It also has the concept of 'Entities', which are named objects (of a type you define) that "live forever", and serialize all method invocations, which are the only way to change their private state. These are also persistent. The Netherite paper [1], section 2, describes this model well.

So, there seems to be a pretty close correspondence between DBOS steps and DF activities, and between workflows and orchestrations. I don't know what the correspondence is to DF entities is in the DBOS model.

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

I may be missing something, but in addition to this threat of prompt injection, you also have to trade trusting the arbitrary MCP server for trusting MCP Defender.

In the default mode, the app will interpose on the communication between, say, Claude, and a local MCP server. It will send the contents of the message (which may include the very sensitive information it is trying to protect) to a remote LLM, which you have to trust. The "scans" will be stored on a log on the server. Not to mention the potential extra delay for every MCP exchange?

This may be more secure, but is it really?

I was using Pocket to save articles to listen to in the car, with their ok TTS feature. Does anyone know of an easy solution that allows me to click to save an article, and then have it automatically on an app on my phone so I can listen while I drive?

This was an interesting quote from the blog post: "There is one silly technique I discovered to allow a LLM to improve my writing without having it do my writing: feed it the text of my mostly-complete blog post, and ask the LLM to pretend to be a cynical Hacker News commenter and write five distinct comments based on the blog post."

It would make it a bit harder to detect that you are using a VPN, but it shouldn't be hard for the ISP to detect that all your traffic is being sent encrypted to a particular IP address.

They wouldn't be able to see you are using X in particular. There may be very specific timing patterns that the X app or the X web app use when fetching related images, new posts, etc, but this also depends on how you scroll the site, and this seems infeasible to prove beyond any reasonable doubt, and also that any ISP would have logs with that granularity. As the parent said, you should make sure no DNS queries go outside of the VPN, for example.

Now, if you post to X, then it would be clear that you used it, which would be a problem according to the resolution, as long as you were in the country.

A long time ago (2011) when I was teaching the networking course at Brown, the final assignment in the course was to create the equivalent of iodine, IP-over-DNS tunneling [1]. Being a course assignment, the handout only outlines the solution. We provided a set of domain names and DNS servers on VMs for students to use.

After the course ended, one student going home did manage to use his assignment to get Internet access from the airport, as we had forgotten to turn off the DNS server nodes.

Over the years we had a lot of fun with creative final projects in the course besides IP-over-DNS, including web-based phone tethering, DNS spoofing, openflow-based SDN routing, LT (Erasure) Coding, a BitTorrent client, and a DNS-redirection-based CDN with leaderboard.

[1] https://cs.brown.edu/courses/cs168/s11/handouts/dtun.pdf

Really great research work from Kay Ousterhout. Sparrow extends the "power of two choices" [1] to a more general formulation, and makes it really cheap to find very good choices (i.e., low-load servers) to run a task, without having to check the load on every server. As the number of tasks and number of servers grow, keeping an accurate picture of the load on every server makes the scheduler become a bottleneck. Kay's work showed a very interesting point in this design space for fast and high-quality scheduling.

Her PhD work went on to really understand the performance of complex distributed programs, like large Spark jobs, and a lot of at least earlier performance instrumentation in Spark is due to her.[2]

[1] https://brooker.co.za/blog/2012/01/17/two-random.html [2] http://kayousterhout.org/

Also, don't call from the same phone you received the call on, if on a landline. One time (I can't find the reference) scammers called from the bank, suggested the person called back to the number on their credit card. The person hung up, picked up, and the scammers had held the line, played a fake dial tone, and had someone else "pick up".

Could not agree more. I think one big problem with Bolsonaro's discourse about the election system -- he was absolutely correct that the current system is not fully verifiable -- is that it became too politicized, and that he or his supporters took this to mean that the election should not be trusted. This automatically made anyone arguing to improve the system be lumped in with those sewing doubts about the result, which eventually led to the backlash from the TSE and the whole Jan 8th debacle.

One big problem with the electoral court in Brazil is that it is the only public branch that concentrates the three powers in one entity: they legislate about elections, they execute the rules, and they judge any matters related to the election. As a result, they have chosen these arguments to shoot down any criticism or improvement suggestions to the election system.

The country deserves a non-politicized discussion on the ground of true technical and security merits of what the election system should be. Paper records with Risk-limiting audits would solve most of the problems. I agree with your [comments] above. The costs of implementing this pale in comparison to the benefits of having a more reliable voting process which is the basis of a strong democracy.

The paper vote records (anomymous, of course) become the source of truth. There are very well established methods (Risk-limiting Audits - https://en.wikipedia.org/wiki/Risk-limiting_audit) that can randomly sample a small fraction of the ballots to guarantee with high probability that the electronic results are correct. Without paper records, the source of truth lies with the code that was run to receive and register the votes, and that is almost impossible to verify and fully trust.

In Networking, two illustrations of congestion control are just fantastic IMO.

First one is [1], by Chiu and Jain (page 7, figure 5), showing that Additive Increase / Multiplicative decrease is the only simple policy that converges among 2 senders (with rates x and y) to a rate that is fair (along the y=x diagonal) and efficient (along the x+y=Bandwidth). This is the basis of the algorithm that made TCP (and the Internet as we know it today) possible.

The other one is this diagram from BBR [2] (from the paper in [3]), that shows how BBR sets the window ("amount in flight") to the bandwidth-delay product (BDP) of the bottleneck link (the "volume" of the pipe in a water analogy). The cool thing is that you can only measure the delay of the link if you window is <= the BDP, and you can only measure the bandwidth if your window is >= the BDP, so the algorithm has to hover around this point to make sure it can determine both.

[1] Chiu and Jain, Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks, 1989, https://www.cse.wustl.edu/~jain/papers/ftp/cong_av.pdf

[2] https://dl.acm.org/cms/attachment/9cf72499-b32d-4426-914b-cd...

[3] BBR: Congestion-Based Congestion Control https://queue.acm.org/detail.cfm?id=3022184

There is a lot of interest on microservices from the research community; there are many open-source frameworks that enable you to write/deploy/operate microservice applications with different levels of abstraction. One thing that is missing in the open is (significant) example applications / benchmarks, across which we can compare the different frameworks in terms of ease of use, convenience, performance, etc. Can you give a description or samples of what people are doing in m3o.com?

Amazon Cash 9 years ago

I was about to make that connection, this is similar to Brazil's boletos. The difference is that in Brazil it is a standardized system that spans all banks: anyone with a bank account that wants to receive money can have their bank issue a "boleto", which is essentially a barcode that routes money to the destination account. A payer can go to any participating place (post office, convenience store, bank tellers, etc) and surrender cash, which then gets routed through the banking system to the right account.

Which brings us to a potential problem: there has been a tremendous amount of fraud in this system (Brazil's Boletos), with all sorts of malware changing the barcode when it is downloaded in an infected computer to issue a boleto with a different destination account.

Back in 2014 this was well documented by Krebs[1], and at amazing detail by @assolini from Kaspersky[2]. I also documented a specific case that happened to a friend[3]. While it should be possible to mount similar attacks on the Amazon system, having people deposit money into others' accounts, it should be straightforward for Amazon to detect this, since it is a single issuer system...

[1] https://krebsonsecurity.com/2014/07/brazilian-boleto-bandits... [2] https://securelist.com/analysis/publications/66591/attacks-a... [3] http://cs.brown.edu/~rfonseca/notes/net-bb-dns-poison.html

Kinderlab Robotics' Kibo Robot (http://kinderlabrobotics.com/kibo/) also features a tangible, screen-free programming language where the instructions are wooden blocks that kids put together in a sequence. They are a funded startup shipping mostly to schools and museums, and the whole thing is backed up by a long line of research first at the MIT Media Lab, and now at Tufts. Previously, the founders created ScratchJr. Worth checking out.