It works by schematising the upstream and making data locally synchronised + a common query language, so the longer term goals are more about avoiding API limits / escaping the confines of the MCP query feature set - i.e. token savings on reading data itself (in many cases, savings can be upwards of thousands of times fewer tokens)
- Claude (via Hubspot MCP) was paginating over contacts, at 40s per 800 contacts and ~150k tokens (triggering compaction)
- full run was 120 of these loops @ 80 minutes and 18M tokens
- Claude + Max was 1 `max search hubspot --filter` command piped to sort | uniq -c
- plus 1 `max search gdrive` query matching each of the results of the previous query, piped to sort | uniq -c
- The rest of the tokens were spent producing an output from 20 words + 20 numbers
This was a particular passion project of mine a while back. I tried building a haptic compass that could be worn on the wrist and discovered that that the actual haptics mattered a lot. Vibration didn't work at all for me (I couldn't internalise the feeling - however much the intensity modulated it just felt like buzzing) but ended up using
a kind of trick of directional "tick" lines to represent proximity to North - which felt almost instantly familiar.
Regarding privacy-first - we're striving to do a good job at this so really appreciate opening up the conversation. We don't actually store consents on our server - unless you enable "logged in mode" as a Metomic customer. When this is the case, you can generate a JWT for your customer that we then use to store a record of their consent serverside.
However for most of our customers, we operate in "anonymous mode", where consents are stored on the browser only. The only thing we do is store an incremental counter on the server that allows companies to see which policies are being accepted and which are not. Whilst we're all figuring out how to be more equitable with users as companies, it's extremely helpful to know when a change you make to a policy is something that people don't support (i.e. reject) - and our dashboard shows you this information
We actually have a community slack channel dedicated towards discussing exactly this type of thing - please do join if you'd like to chat!
I really like this. It's a pretty elegant way to handle iframe content in particular. Will keep a keen eye on this project!
The issue we ran into in this area was with embeds that don't use iframes - generally it ends up being a third party script that needs innoculating (e.g. instagram / twitter embeds), with a bunch of associated dom content somewhere else on the page (the new facebook embeds work the same way).
The approach we've thus taken is to allow you to bundle related content together under a single "purpose" - when permission for that purpose is granted, all associated content gets unlocked.
Our mission: to build the missing trust infrastructure of the internet.
We know that building apps is hard enough. Building apps whilst getting data-privacy _right_ is herculean - see GDPR, CCPA etc. The developer world is sorely missing an abstraction, and we want to fix that. We are creating the building blocks that enable APIs and SDKs to talk the same language about privacy.
We're a small, well-funded early stage startup with a massive mission. If solving big problems sounds like fun, come say hi!
Metomic (https://metomic.io) | London | ONSITE | Backend Engineer and Fullstack
Our mission is to build a new standard for data privacy and data ethics.
We believe strongly in the power of sharing data, but we realise that consumers need controls and transparency before they can trust companies with it. And we believe that the way to get this right is to make it as _easy as possible_ for companies to do the right thing.
So that's what we're building. Technology that watches technology, helps make sense of the all-too-common mess of sprawling internal data flow, and a consumer facing plug-n-play user-experience to close the loop.
We just launched a consent manager on ProductHunt (on Wednesday) and reached #2 product of the day
We're still an early seed-stage startup with competitive salaries and equity to boot. As an early member, you'll be helping us define the future of this space. If you like autonomy, ownership and have opinions ... come say hi!
Metomic (https://metomic.io) | London | ONSITE | Backend Engineer and Fullstack
Our mission is to build a new standard for data privacy and data ethics.
We believe strongly in the power of sharing data, but we realise that consumers need controls and transparency before they can trust companies with it. And we believe that the way to get this right is to make it as _easy as possible_ for companies to do the right thing.
So that's what we're building. Technology that watches technology, helps make sense of the all-too-common mess of sprawling internal data flow, and a consumer facing plug-n-play user-experience to close the loop.
We're an early seed-stage startup with competitive salaries and equity to boot. As an early member, you'll be helping us define the future of this space. If you like autonomy, ownership and have opinions ... come say hi!
Metomic.io | London | ONSITE | Fullstack dev, devops / React dev / Growth Lead / UX,UI,Product Designer
Our mission is to build a new standard for data privacy and data ethics.
We believe strongly in the power of sharing data, but we realise that consumers need controls and transparency before they can trust companies with it. And we believe that the way to get this right is to make it as _easy as possible_ for companies to do the right thing.
So that's what we're building. Technology that watches technology, helps make sense of the all-too-common mess of sprawling internal data flow, and a consumer facing plug-n-play user-experience to close the loop.
We're an early seed-stage startup with competitive salaries and equity to boot. As an early member, you'll be helping us define the future of this space. If you like autonomy, ownership and have opinions ... come say hi!
Not sure why onetimePete is being downvoted. Although worded unusually, I concur with his implication - that after some time, advancements in this kind of technology will likely move us towards a ubiquitously augmented world. Although I personally expect we would settle on an open protocol for sharing and receiving public / private augmentations, it makes sense that the organisations who control augmentation technology wield an awful lot of power. Principally, the ability to make the world look, to you, however they want it to... perhaps subtly.
I would argue that "dependency injection" at its purist is little more than the side-effect of designing with intent to minimise module responsibility.
When writing a class, as a rule of thumb I'd posit there's a general advantage to outsourcing units of behaviour or complexity to other modules. Those other modules could be constructed by the class itself, but this is likely to make the current class concerned with the construction details of those modules. One of the simplest things to do, for example, is to ask for those modules to be provided to the class on construction.
This sounds like a great idea until somebody comes along and calls it "dependency injection" and a bunch of us lose our minds.