What’s the purpose of the read-only link if it has the same UUID?
I just built it without a backfill, new data should have a full read-only hash -- I'll try to backfill the data tomorrow
Show HN: Textdb.dev – simple data sharing for fun projects
51–60 of 79 posts
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#52Very cool! Do you have any sort of dashboard displaying stats for the service? Simple totals would be interesting, of course (size, # of buckets, # of edits, etc.), but I'd find histograms of edits etc. per bucket particularly fascinating.
I don't yet, but let me get back to you in a couple days. I think it'd be interesting to all.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#53I really like simple tools like this. Well done; I can see lots of uses for this, especially with the Serverless/Jamstack surge. I love the idea of Hashing and read/write keys mentioned in this comment: https://news.ycombinator.com/user?id=miki123211 I also like the idea of batch requests so you can pul multiple keys at once, or set multiple keys at once. It seems better for everyone. My only concern is that a small…
Thanks! So far the limits are about 500Kb, which is more than enough for what this service is intended for.
The setting of multiple keys I'd have to think about, as it's already so easy to acquire multiple keys -- ie I don't think I'd be saving or making anything much faster by special handling for it. Pulling multiple keys is likewise, you're free to do it in an async all.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#54Great work! I wrote something similar at:
It's useful if you set up bash aliases like "push" and "pull" so you can quickly move snippets of text across servers.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#55This seems to be in a similar spirit to https://patchbay.pub/ . I love these small services, but I still don't have an idea how they can be scaled up: If you want to use them for anything serious you probably have to prevent abuse and comply to all kinds of regulations.
Yeah they're nice and fun to build. I imagine if you wanted to, you'd run this behind a VPN at #corporation, which will be a huge pain to get approval for, but not that bad.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#56Earlier quoted context omitted.
Thanks 8), rate limiting is just the most basic of nginx configs to like, 10 requests / second / ip
Really simple cool! One minor thing on the IP rate limiting side.... LOTS of mobile/cell users might end up NAT'ed behind a single IP. Just an FYI.
That's a good point. How does one rate limit correctly in that case?
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#57I'd already been pondering the paperclip-machine universe that could be created by a Twitter bot that just pipes tweets to bash and posts the output.
Now it could just trawl Twitter for addresses at https://textdb.dev, and throw the contents through bash, post the result back to textdb, and tweet a new link... :]
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#58Earlier quoted context omitted.
It's a cool idea, but the old anti-pattern about security through obscurity applies.
People get this wrong a lot. Security only through obscurity is no security at all. The argument was generally made in the context of secret, proprietary encryption algorithms. In this context, it was frequently true - security reduced to reverse engineering. But security isn't a thing. It is a property of a system. And many secure systems strategically employ obscurity for multiple purposes. Reciting a mantra is a p…
Right, but in the context of this application, there is NO OTHER security except the obscurity of the UUID or it’s hash. The mantra applies quite well here since an attacker could stumble upon a valid hash or UUID and then change the data.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#59Earlier quoted context omitted.
Really simple cool! One minor thing on the IP rate limiting side.... LOTS of mobile/cell users might end up NAT'ed behind a single IP. Just an FYI.
That's a good point. How does one rate limit correctly in that case?
I don't think it's possible to correctly rate limit IPs behind NAT, at least with NGINX.
> Note that IP addresses can be shared behind NAT devices, so limiting by IP address should be used judiciously.
https://docs.nginx.com/nginx/admin-guide/security-controls/c...
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#60I'd already been pondering the paperclip-machine universe that could be created by a Twitter bot that just pipes tweets to bash and posts the output. Now it could just trawl Twitter for addresses at https://textdb.dev , and throw the contents through bash, post the result back to textdb, and tweet a new link... :]
That's a neat idea too, I love hearing all these new ways to use a simple bit of data.