sean_lynch

Before you get too far into the usual “MCP is dead, Skills forever” debate

The real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent’s context window, and potentially out of the harness completely. This is valuable from a security perspective obviously. It’s also just a much easier user experience for normies and large businesses adopting AI tools. I hear all the context bloat and tool call redundancy complaints. But this structure for handling auth has real value.

Maybe the idealized form of MCP is just an auth gateway for the API and nothing else. That’d still be a win.

I’d love to hear more. What are they seeing?

I’m getting “Invalid captcha” when asking the first question. I’m on iPhone and not seeing any captcha. Any advice?

I'd love to hear the bull case for standalone vector DBs at this point. After exploring a few, there's not much differentiation from what's offered here (beyond maybe a nicer developer experience than GCP's) and I'd expect many other DBs/data warehouse to follow the same path as BigQuery has.

It looks like there's still plenty of hard problems in the indexing side of RAG and so maybe the vector DB that leans hard in that direction will carve out something defensible? Outside that, can't find a good reason to standup yet another piece of infrastructure purely for vector search.

Not even the only McDonald's branded game of the era! I played MC Kids growing up on NEWS and it also was a dramatically better game than it had any right to be. Not quite the same storied history but still recommend playing if you're looking for some hidden NES gems.

https://www.youtube.com/watch?v=7nKywTkMnAs

https://en.wikipedia.org/wiki/M.C._Kids

OpenAI actually thinking about this too. It’s buried in their open source repo and not clear the exact mechanism that ChatGPT knows to make use of it. But we’re already here evidently.

https://github.com/openai/chatgpt-retrieval-plugin#memory-fe...

Have been thinking about exactly this workflow and of course Simon is way out ahead. I recommend taking a look at Simon's daily notes logs too, really fascinating back and forths.

I’m assuming this is a sell page for eng candidates? I think you should mention the big engineering challenges you have at Streak. You mention you’re the largest Spanner user outside Google. That's a really impressive point, but what problems are you tackling by using that?

FWIW - I don’t like that you stuffed everyone into the same t-shirt :)

This is incredibly interesting, thanks for sharing. The actual applications are also available here:

https://www.sfmta.com/reports/original-2018-scooter-applicat...

I'm interested in GraphQL but definitely haven't been following closely.

This seems to be a marketing video for Apollo's products. Is that what most GraphQL stacks look like in production these days?

Curious where you need it stored. EU? Or anywhere outside US?

I've been looking for a service like this. Thanks for flagging!

This is awesome, really want to see more of gmail become a platform.

iOS, Android, JS, OS X, Python, or just plain ol' HTTP :)

http://dropbox.com/developers/datastore

While I can't comment on this specific case, I do want to say there is a tremendous amount of rigor (and layers of protection) to ensure the end clients are resilient to misbehaving computers and do the right thing. For example, you shouldn't have to worry about the clock being accurate as it has no bearing on the final sync state.

Just to dive in a bit for the HN crowd: We base the changes that should be applied to your Dropbox on whether the client has successfully synced the previous version of the file. The server doesn't allow the client to apply changes unless the client is fully up to date. And in the case of deletions, the desktop client is only permitted to issue deletes to files that have been successfully created on disk and then later deleted.

We also have a proper support team to catch things that fall through the cracks, and if you have issues, you should reach out to them first (and as soon as you notice; their ability to fix things becomes harder the more changes you make to your account).

Again, not commenting on the above issue, but I did want to point out that we take the integrity of your data very, very seriously.

When migrating an account into a team, the account and all the data in the account becomes managed by the Teams admin (shared or otherwise). Letting an existing account to join a team lets us smoothly support the situation where a user has created a Dropbox account separately and needs to move that account into the team.

For most cases though, users should create a new account for the team. The Dropbox for Teams sign up process guides users towards creating a new account when joining a team for this reason.

Hey guys - Dropbox product manager here,

tl;dr: The scenario described by the OP is now less likely to occur. Since October, individual Dropbox users are encouraged to create separate accounts when invited to a Team and warned that Teams admins will have control over the account.

We want individual and Team Dropbox users to have the best possible experience. Some users want to migrate their personal accounts into a Team. Others are much happier with separate personal and Teams accounts. We’ve been working to make that choice much clearer for the account holder and the Teams admin.

If users do choose to merge their personal account with a Team, things become a bit tricky. Teams admins want better control of data within a Team, and users want easy access to their personal stuff, but it’s not possible for us to differentiate between Team data and personal stuff in the same account.

Here are some thoughts on the points raised by the OP:

* Better support for multiple accounts: Users can quickly switch between using personal and Teams accounts on the web today and we intend to make this better across our platforms.

* Improved messaging to Teams admins: We plan to provide better messaging to admins before disabling an account that was migrated in.

* Disabled accounts are not immediately deleted: We can work with Teams admins and users to sort out account issues and recover users’ files.

We’ve contacted the OP to help resolve his case and are sorry for any pain this caused!

It is indeed. One of the amazing things about the YC program is the amount of support we received from the partners and other companies when we were facing the decision.

We're not staying in the same space so I don't think we'll want to spam our current set of beta testers with our new product. If you track me down on Twitter though (sean_lynch), I'll send you a heads up when we launch.

I've got all the parts of a good postmortem post floating around in my head. Unfortunately, it's probably going to have to wait a few weeks while we tackle our new product.

Yeah, it sucks :( If there's anything we can do to help transfer your data back, please let us know.

Both an Android and an iPhone versions are looking for beta testers :)

We're both very big Billmonk fans, but unfortunately the application hasn't seen very much improvement since it was acquired a few years ago. Splitterbug helps you solve the same problem using some very cool tech that Billmonk didn't have access to (native iPhone apps/Android/Facebook graph/etc).

Our primary focus right now is building an app solves the problem of splitting bills and tracking debts. We've got a few ideas about monetization, but if we can't build a useful app first, that discussion is moot.

Good eye :) The web version lacks a lot of optimizations we were able to add on the client though. If you're excited to start using the thing now, shoot me an email at support [at] splitterbug.com and let me know what device flavor you prefer (iPhone/Android). I'll get you set up.

We have both iPhone and Android clients and we're looking for beta testers for both.

Launched, although not particularly large (www.splitterbug.com). What becomes difficult to manage when you introduce customer data?

Disclaimer: In a past life I was a PM on App Engine (and not surprisingly, we're using it for our new company), so the following comment has a fairly high bias.

Though it doesn't have the same HN buzz that Heroku does, App Engine has a fairly large developer community and a lot of applications using it. Like almost all PaaS product, there are restrictions that limit what you can do (library support, native code support, etc) and these limits frustrate developers that go in expecting the same experience as having a virtual machine. The limits mean that App Engine isn't the right solution for every application under the sun. But if your application doesn't have super unique requirements, the value that App Engine provides is hard to beat.

Ten second deployments, one click version management (and roll back), logs and monitoring, and autoscaling mean that we can be really agile pushing new versions of the application. App Engine's recent changes to the scheduler and Always On feature have really solved the slow instant start issue that still plagues a lot of Heroku developers. Last year the datastore had a ton of performance and reliability issues, but the new high replication configuration appears to have solved the problem. The biggest issue for us is the one that's mentioned here a couple of times and that's SSL.

For now, App Engine is nearly perfect for us. If we end up with unique requirements, we can definitely spin up a few EC2 instances and hook them up to App Engine's Task Queue. But I'm not excited about having to manage machines. Personally, if we hit a limit with App Engine, we'd be looking to another PaaS offering like Heroku or dotCloud, or Infrastructure as a Service like MongoHQ/RedisToGo before bothering to deal with machines again.

Member of the App Engine team here. Yes, to confirm, this is not an abstraction on the current Datastore but a separate "real-deal" service.

Agreed and bonus points for using a map of Vancouver :)

Email sent. Google here, confirming this is an issue with the Users API on App Engine. On-call team is working on the fix now.

Edit: As of 12:30PM PST, we are now rolling out the fix. This should be relatively instantaneous.