pinehqcom
Joined 7 years ago
Karma
19
Submissions
36
Member since
Nov 12
Recent submissions
Comment · 4 years ago
Great question Freemade, we use https://crypto.stanford.edu/sjcl/ for the encryption. It is pretty straighforward. The password (as per my main message) is saved suffixced on the url with #. E.g. #mysecretpassword. This is because hashes are never sent to the server.
Comment · 4 years ago
Thanks Raed, We are changing it to "Messages are encrypted in your browser to ensure they are not even accessible to us" per your suggestion on Monday :)
Comment · 4 years ago
Hey ibdf, great suggestions. I think the "If not visited delete after" is lot better wordwise!
Ps. what does your name stand for? ibdf?
Comment · 4 years ago
That's a good point. I'll find another way to express it. Thank you mtmail
Comment · 4 years ago
I considered building something similar OnlineOrNot for many years now since I needed to validation of e.g. json.
I'll definitely check it out!
Comment · 4 years ago
Hey HN!
I am a part of a small IT business and like many of you, we face the constant problem with securely sharing passwords between clients and between coworkers. Of course, there are systems for this, but with busy schedules or mere complacency, it's a challenge to get all involved to set up these services accordingly. Failure to do so means that the passwords to accounts with critical user data often end up as contents of non-encrypted email messages or other equally unsafe means of communication. Confidential files share the same fate. We decided to take a different approach instead, which we think balances ease of use with security.
We named the service Duckist.com and with it, you can generate self-destructing messages containing either text or media, that are encrypted on the client-side. This means the server never actually sees the unencrypted message.
# Technical
This is only relevant if you'd like to know what's under the hood, which I know many of you guys here, certainly are :)
What we do is use the browser to create a password that is then used to encrypt the message on the client-side. The encrypted message is sent to the server and on the frontend side we generate a URL such as this:
https://duckist.com/msgs/messageID#password
How is that beneficial? When a person visits this URL, then the browser won't send anything the hash to the server. This means that when someone reads the message, Duckist.com never sees the password.
To see this is actually true, pop up the terminal with `netcat -l -p 9001` and input http://localhost:9001/hello#mysecret into your browser. You'll observe that `mysecret` was never sent to the server.
To see we are sending/receiving the messages encrypted you can use the browser's inspect functionality.
We saw the benefit of the tool's existence and decided to turn it into a public project hence I'd love to get your feedback. I am thick-skinned so just come at it in full HN style :)
This is actually an old project that we decided to rename, revive and improve. I previously wrote about it here: https://news.ycombinator.com/item?id=21513362
Comment · 6 years ago
I understand the no js/plugins, but why not a static site generator?
Static site generators (at least most) are the only "new" technology that seems to make things simpler instead of more complicated, and SSGs are a massive time saver regarding themes, sitemaps, robot, optimization, etc.. and there are no dependencies at all.
It also helps me writing.
I run `hugo serve` that autorefreshes in the background, then I have split up my screen with right being my vim and right my browser.
Takes 1 second to see the result of what I am doing.
Comment · 6 years ago
This... I just found a plugin for the static site generator Pelican that is 7 years old that still works.
After running Pelican you get plain HTML that can be hosted anywhere.
I like Netlify, but other options like GitHub pages are also great.
The author recommends not putting on GitHub Pages because they haven't found a working business model and might not be here in the future.
But... GitHub has been taken over by Microsoft which is most likely not going bankrupt soon and Microsoft loves their backward compatibility so I am confident they won't screw GitHub up too much.
Comment · 6 years ago
Thanks again Jetti!
Comment · 7 years ago
Thanks for taking the time to read and go write this super beneficial feedback Jetti!
1.) The reason why I choose httpie over curl is that it is a lot shorter and just show the essential instead of setting the applicaton/json and having json as a string, but you're right. I'll translate all the examples to curl in the next coming time.
2.) The APIs do not fit the standard CRUD/Resource (Rest) approach. Our small team discussed a lot about how to do it and tried different ways but it made it harder to remember was it with a POST, or GET? Both kinda made sense, and what when you wanted parameters with as GET?
3.) We will be adding a tonne. First, we wanted the platform up and running as basic as possible. We got inspired by the "API Marketplaces" where everyone can upload an API, but we want to address the problems with poor quality, latency, and documentation. The idea is to have one place to use/pay/do.
Almost nobody signed up compared to the visitors we got from HN. Can I ask you if you signed up or not and how come?
Comment · 7 years ago
Maybe you are like us, tired of spending hours on complicated APIs with incomprehensible documentation. We decided it was time to fix this.
We are trying to make it easier to be a developer in 2020 and beyond, by making functionality available through an API. This way, you won't need to implement it yourself or use a library that might break upon updates or other weird stuff.
What do we do for you?
* Lots of reusable things to use to make your own software faster * The API will always be compatible with previous issues * Technical Support - talk with our engineers whenever you need us * Provide you with documentation just the way you want it
Try it for free without having to submit any credit card details. You can signup here https://app.apijack.com/accounts/signup/ and see our documentation here: https://apijack.com/docs/
I'd love to hear from you - what can you use, what can't you use?
Did you find any bug? Is there anything that you'd love us to add? Any specific API you'd like to have integrated in apiJack?
Don't be shy! Send us your feedback!
Comment · 7 years ago
I setup this alternative for Medium, https://bun4.com. Make a Pull Request on https://github.com/pinehq/bun4 and it automatically compiles. Stop complaining and start writing ;)