41–50 of 80 posts
Earlier quoted context omitted.
Are you looking for investment? Happy to close the deal, love that idea so much and trust the co-founders redwoodjs ;-)
Unfortunately not anymore, we have a great set of people backing us, but thanks for the vote of confidence. As an aside: Not exactly sure why the parent is getting down voted.
> Based on policies you define, individual fields can be encrypted/decrypted... Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything? Or is it more granular even within the main app? Like can I teach JumpWire about my app's users and our AuthZ ruleset?
> or they partition the data by putting some fields in a data vault and others in the main database I was considering using VGS to tokenize sensitive data, but I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?
> We’ve seen entire teams dedicated to just maintaining ETL pipelines for scrubbing PII into secondary databases!
I do this to make staging environments more realistic, which makes them double as debugging tools on production when you can't give engineers any sort of direct production access. We whitelist non-sensitive fields (most importantly foreign keys), and fill in the rest with faked data. The app looks like production, but if all the users were bots who were saying nonsense at each other. At my scale (50 person company), it works reasonably well enough with just me maintaining it.
Have you thought about solving the problem from a different direction? Providing a read-only, sanitized clone of the database that can be accessed outside of the core application code? Seems like that could kill more birds with the same stone?
Earlier quoted context omitted.
Unfortunately not anymore, we have a great set of people backing us, but thanks for the vote of confidence. As an aside: Not exactly sure why the parent is getting down voted.
Yeah, that's wierd. I just upvoted you to compensate.
Earlier quoted context omitted.
That's exactly what we're doing at https://www.snaplet.dev , I would love to chat with the founders about offering generated production accurate snapshots for developers to code against for users of their proxy!
Happy to chat anytime! You can reach me by email (ryan at [ourdomain]) or book directly on my cal - https://calendly.com/ryan-jump/yc-founder-meeting We've peeked at Snaplet in the past, and :heart: your design aesthetic
Earlier quoted context omitted.
Happy to chat anytime! You can reach me by email (ryan at [ourdomain]) or book directly on my cal - https://calendly.com/ryan-jump/yc-founder-meeting We've peeked at Snaplet in the past, and :heart: your design aesthetic
Thanks! I'm just about to catch a flight, but will reach out when I get back to the land of the living!
Any comparisons to https://www.tonic.ai ? > Based on policies you define, individual fields can be encrypted/decrypted... Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything? Or is it more granular even within the main app? Like can I teach JumpWire about my app's users and our AuthZ ruleset? > or they partition the data by putting some fields in a data vault a…
> Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything?
Yep, that's exactly right. Application credentials are grouped under classifications, and policies can be included/excluded across classifications. We aren't passing authz through JumpWire but for something like Retool you can configure it to connect through different proxies for different users.
> I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?
Exactly. The engine which interacts with your data is almost always self-hosted, and the web app also can be if needed.
> At my scale (50 person company), it works reasonably well enough with just me maintaining it.
Makes sense! No reason to add more tools to your stack yet if the custom process isn't too burdensome.
Looks great. How do you guys compare to something like Voltage?
The value prop is definitely very similar. I'm not as familiar with Voltage as I am with other solutions, but my understanding is that it requires either using the Voltage database driver (JDBC/ODBC in particular) or an HTTP API. With JumpWire, all of the works happens in an engine proxy that works directly with the database protocols. That makes the integration simpler - any language and connector can be used by jus…
Earlier quoted context omitted.
Are you looking for investment? Happy to close the deal, love that idea so much and trust the co-founders redwoodjs ;-)
Unfortunately not anymore, we have a great set of people backing us, but thanks for the vote of confidence. As an aside: Not exactly sure why the parent is getting down voted.
I'm not saying that your post was such a hijack, but it's difficult to interpret these things accurately, so any post of this kind will always land on a spectrum of responses.