61–70 of 129 posts
The built-in server and remote support is pretty nice! API seems solid, and I dig the QR codes.
Qr codes are pretty cool just a shame it never really took off.
In that sense it took off more than bitcoin.
Earlier quoted context omitted.
Isn't that the whole point of "Show HN"? Or what do you expect when you click on a "Show HN" story?
I expected to learn something from it - especially when it's popped on the front page of HN. Am I expecting too much of HN? My train of thought when I saw the link "a key-value store": what data-structure are they using? A hashmap? How are they resolving conflicts? Is it in memory? How are they persisting data? Do they support multiple instances? What about concurrency? etc. Of course I might be a bit disappointed wh…
Earlier quoted context omitted.
Qr codes are pretty cool just a shame it never really took off.
What do you mean it didn't take off? QR code detection is implemented in native iOS camera and IIRC most android implementations too. Almost everyone can use it. In that sense it took off more than bitcoin.
Earlier quoted context omitted.
Isn't that the whole point of "Show HN"? Or what do you expect when you click on a "Show HN" story?
I expected to learn something from it - especially when it's popped on the front page of HN. Am I expecting too much of HN? My train of thought when I saw the link "a key-value store": what data-structure are they using? A hashmap? How are they resolving conflicts? Is it in memory? How are they persisting data? Do they support multiple instances? What about concurrency? etc. Of course I might be a bit disappointed wh…
For personal use, I’ve had good luck storing things in files. Then when I need those those things, I read the files.
Earlier quoted context omitted.
This seems unnecessarily snarky. You can make anything sound silly by reducing its functionality to the most basic level possible, ignoring all aspects of ergonomics and packaging. And you could make this comment about any storage engine. Like the infamous Dropbox comment here.
What's wrong with Dropbox comment? I still didn't find any use for this service, but rsync works for me almost every day. IMO Dropbox is useless.
Earlier quoted context omitted.
This seems unnecessarily snarky. You can make anything sound silly by reducing its functionality to the most basic level possible, ignoring all aspects of ergonomics and packaging. And you could make this comment about any storage engine. Like the infamous Dropbox comment here.
What's wrong with Dropbox comment? I still didn't find any use for this service, but rsync works for me almost every day. IMO Dropbox is useless.
For personal use, I’ve had good luck storing things in files. Then when I need those those things, I read the files.
For the README, I'd hope to find a bit more information about the way data is stored and transmitted. For example, this seems to just be a SQLite database with values in fields? Is there a separate encryption key for the database itself? Otherwise anyone with access to the file would be able to see all data stored?
The encryption key is only used to encrypt data in transit, but not at rest? And then you're encrypting the full JSON blob instead of only the values? This seems risky to me.
What is the purpose of the ProcessID? It is randomly generated and stored in the database (thus used by all clients too). So, I'm not sure what this is for? I see it's used to resolve conflicts, but these should probably be given out by the server?
Do the clients cache data locally? It looks like you're basically syncing from the server for every request. You're already making a round trip to the server for a request anyway, so why not keep state only on the server? I can understand an offline-only mode, but this would require a significantly more robust sync mechanism. If this was the goal, I'd love to see this discussed more in the README too.
Finally, I don't understand why you're using plain HTTP (no TLS) for communication b/w client and server. I didn't see any authn/authz in the requests. You're also unmarshalling random data from the request w/o confirming that it is valid first. This seems risky to me and could potentially crash the server if I were to send it random data.
This would have been a great use-case for a simple (non-HTTP/JSON) TCP server:
>>> AUTHTOKEN xxx
>>> SET $KEY $LEN $SHA1
>>>
>> AUTHTOKEN xxx
>>> GET $KEY