[HN Gopher] Show HN: Textdb.dev - simple data sharing for fun pr...
___________________________________________________________________
Show HN: Textdb.dev - simple data sharing for fun projects
Author : bontaq
Score : 172 points
Date : 2020-07-25 10:57 UTC (12 hours ago)
(HTM) web link (textdb.dev)
(TXT) w3m dump (textdb.dev)
| webmaven wrote:
| Very 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.
| bontaq wrote:
| I don't yet, but let me get back to you in a couple days. I
| think it'd be interesting to all.
| tannercollin wrote:
| Great work! I wrote something similar at:
|
| https://reg.t0.vc
|
| It's useful if you set up bash aliases like "push" and "pull" so
| you can quickly move snippets of text across servers.
| bontaq wrote:
| I see some of you are realizing that I haven't enforced any data
| url to be a UUID, good on you. I hope it opens up new neat things
| like https://textdb.dev/data/hello-hackernews or more creative
| ideas.
| ASVVVAD wrote:
| That's awesome! I was wondering if I had to go to
| https://textdb.dev using the browser to get an ID x)
| bontaq wrote:
| Nah it just gives you a more secret id, I'm happy to support
| people talking about apples at https://textdb.dev/data/apples
| unixfox wrote:
| Alternative service except there is no live update:
| https://jsonbox.io/
| berkas1 wrote:
| Hi, is the source code available? :)
|
| BTW, the front page's HTML seems to have a <head> and <body>
| inside another <body>.
| bontaq wrote:
| Sure, I just made it public over here:
| https://github.com/bontaq/textdb
|
| Yeah I'm not sure why it's doing that, v annoying though
| cocktailpeanuts wrote:
| probably you have a layout bug. it's wrapping a layout within
| a layout.
| bontaq wrote:
| Yep that was it, ty, it should be fixed now
| gmemstr wrote:
| Is there an upper limit to the amount of data that can be stored
| on an endpoint?
| bontaq wrote:
| There currently isn't, but it is intended for small amounts of
| data. Today or tomorrow I'll probably put a cap at 500Kb or so,
| which is still a heckload of data.
| josefrichter wrote:
| One more question: Does the data expire?
| mhass wrote:
| Very cool. Are you using just cowboy as a server or do you have
| nginx/Apache in front?
| bontaq wrote:
| nginx is in front, but it's just doing a proxy and setting some
| headers, so effectively cowboy's serving everything.
|
| So far it's doing a great job too, CPU is at 2%, 1Gb free ram
| of the 4Gb available, and a pretty constant 1Mbps outward, on
| the 20$/m digital ocean droplet. I may have jinxed it by saying
| this though.
| WrtCdEvrydy wrote:
| This is fancy...
| rendall wrote:
| Is there a maximum file size limit?
| known wrote:
| Similar service https://u.instacrypt.me/
| mkoryak wrote:
| No, it's not.
|
| Your link is a message service that self destructs.
|
| OPs link is a storage service
| abathur wrote:
| I'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... :]
| bontaq wrote:
| That's a neat idea too, I love hearing all these new ways to
| use a simple bit of data.
| lou1306 wrote:
| I'm pretty sure you could build a Turing machine with textdb as
| tape and a Twitter bot as the tape head.
| redm wrote:
| I 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 portion of users will undoubtedly
| try to abuse this with high volumes or large objects, or both.
|
| Have you published any limits on value key size, value size,
| read/write limits for keys etc? It might be worth thinking about
| now before you have to shutdown users or shutdown the service due
| to cost.
|
| Congrats again!
| bontaq wrote:
| 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.
| erezsh wrote:
| Cool idea, nice implementation. But man, fix your README.md!
| bontaq wrote:
| Made because I couldn't find a simple, no-sign-up service to sync
| a list of names for a command line tool. And resubmitted because
| yesterday I goofed and the curl commands listed didn't point to
| the right location, which really took the fun out of it.
|
| Favorite part of the project: trying out Phoenix's built in pub
| sub + live view (the live view subscribes to a data/:id topic,
| which the api write endpoint publishes to) to get that nice
| instant update on write if you have the data open in the browser
| without polling.
|
| It's also fun to see how fast it syncs multiple browser windows
| watching the same data when you edit it in one window. That's not
| useful, but I give it 1 "neat".
| chris_st wrote:
| That's pretty cool! Are you doing anything like rate-limiting
| to prevent abuse?
| bontaq wrote:
| Thanks 8), rate limiting is just the most basic of nginx
| configs to like, 10 requests / second / ip
| NetOpWibby wrote:
| Oh nice, that sounds simple enough.
| sreekotay wrote:
| 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.
| blisseyGo wrote:
| That's a good point. How does one rate limit correctly in
| that case?
| lioeters wrote:
| 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...
| nickjj wrote:
| Hey, if you ever wanted to come on my podcast to talk about
| your tech stack (how it was developed, deployed, lessons
| learned, etc.) I'd love to have you on.
|
| There's a few Phoenix episodes out currently, but none are
| using Live View yet. It would be really fun to talk about how
| someone is using it in production.
|
| If you do, head over to https://runninginproduction.com/ and
| click the "become a guest" button on the top right to get the
| ball rolling.
| spery wrote:
| Manually editing data has a bug. If you click cancel it will
| still update the value.
| bontaq wrote:
| Thank you, fixed
| TedDoesntTalk wrote:
| What language is this? I visited
| https://www.phoenixframework.org/ and even watched a few minutes
| of a video but there's no mention of the programming language. I
| suppose the language is called Phoenix?
| detaro wrote:
| It's Elixir.
| TedDoesntTalk wrote:
| huh. I would have thought https://www.phoenixframework.org/
| would mention Elixir then.
| detaro wrote:
| It does in a few places, not very obvious though,
| especially if you might not know that "Elixir" is a
| programming language, agreed.
| dmitriid wrote:
| Elixir (on top if Erlang VM)
|
| - https://elixir-lang.org/
|
| - https://www.erlang.org/
| mkoryak wrote:
| Can you add a link to your GitHub from the website?
|
| I usually star things instead of bookmarking and others probably
| do too.
| NetOpWibby wrote:
| https://github.com/bontaq/textdb
| ximm wrote:
| The HTML of the frontend is messed up (<head> is duplicated)
| bontaq wrote:
| Should be fixed now 8)
| josefrichter wrote:
| Whoever made this, I love you. I do a lot of prototyping in
| Framer, and this just make simple prototypes that communicate
| with one another hell of a lot easier!
| StavrosK wrote:
| You may also like this super simple MQ I wrote a while ago:
|
| https://www.stavros.io/posts/messaging-for-your-things/
| bontaq wrote:
| Hell yeah, I'm planning to keep it up for a good while and
| lemme know if something isn't working or you'd like a new
| feature. bontaq @ the google mail .com
| WA wrote:
| What's the purpose of the read-only link if it has the same UUID?
| bontaq wrote:
| I just built it without a backfill, new data should have a full
| read-only hash -- I'll try to backfill the data tomorrow
| ximm wrote:
| This 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.
| anderspitman wrote:
| I didn't design patchbay to scale. I think of it more as a
| hammer, or maybe a Swiss army knife. Things can be useful
| without scaling.
| bontaq wrote:
| 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.
| jrott wrote:
| Thank you for making this it's super handy.
| miki123211 wrote:
| It would be cool if it was possible to read the data not just by
| the ID, but also by the hash of the ID.
|
| That would let us serve stuff like version information and links
| to the latest version, without the fear that somebody is going to
| reverse engineer our app and replace the data with something
| malicious.
|
| We, as the app author, would have the full key, so we could read
| and write, whereas users would have nothing but the hash.
| bontaq wrote:
| That's a cool idea, I'd definitely like to add the ability to
| create a little store with more safety, and that totally works
| with the goal of simplicity. I'll give it a shot.
| TedDoesntTalk wrote:
| It's a cool idea, but the old anti-pattern about security
| through obscurity applies.
| _jal wrote:
| 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 poor substitute for carefully
| considering your problem domain.
| TedDoesntTalk wrote:
| 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.
| bart__ wrote:
| I never really understood this argument, obscurity add an
| obvious layer of protection, not impenetrable of course,
| but still valid. Why is this different than an API key for
| example?
| gregmac wrote:
| If compromised, you can change an API key. The key is
| like a password, and keeping that secret is important.
|
| Where the "obscurity" aspect comes in, as an example, can
| be through the mechanism used to generate and validate
| that key.
|
| Let's say you decide you don't want to or can't store the
| keys, and don't want a full pki system (public/private
| keys or certificates), so go with: sha256(clientid +
| userid + "hardcoded secret"). Your security now 100%
| relies on no one knowing that algorithm. If someone
| figures it out, you need to release a new version of your
| software, invalidate ALL API keys, and for that effort
| you still haven't done anything to prevent the same thing
| happening again.
|
| A good test of this is: if someone has your source code,
| can they break your security mechanism? If yes, you're
| probably relying on security though obscurity. By
| contrast, if you're using asymmetric encryption to
| generate keys, it doesn't matter if someone knows that:
| if they don't have the private key, they can't do
| anything. (This leaves aside the issue of storing your
| private key or other secrets in source code, but I'd
| describe that as an operational failure rather than a
| fundamental design problem).
| Chickenosaurus wrote:
| If a cryptographic hash function is used, the security of
| this scheme doesn't rely on keeping the algorithm secret,
| though. Therefore, it's not security through obscurity.
| Of course, weaknesses could still exist (e. g. a too
| small input space because the ID that is hashed has too
| little entropy).
| melq wrote:
| Security through obscurity refers to relying upon keeping
| the details of the security mechanism secret. An API key
| itself is a secret, but the mechanism for how that key is
| generated and used is public knowledge.
|
| In fact, the reason the best security mechanisms used
| today are so robust is specifically because they are made
| public in the first place.
| [deleted]
| bontaq wrote:
| It is done, lmk if it works alright. The read only hashes
| should be visible beneath the data editing view on a new one.
| ASVVVAD wrote:
| Adding it to the homepage would be cool too ^^
| bontaq wrote:
| How would you phrase it?
|
| "write only link here"?
|
| I really wanna keep the basic information visible and am
| not sure about about adding another line
___________________________________________________________________
(page generated 2020-07-25 23:00 UTC)