I'm not trying to be rude, but does this do anything more than I can do by saving a web page with "Cmd + S", and storing that saved web page in my cloud storage? My way avoids bit rot, makes it available anywhere, and since my cloud storage is private, no one knows what I'm saving.
Does this just stash the URL del.icio.us style, or does it actually archive a copy of the page contents for me? I stopped using the former before it even went defunct, because link-rot made the whole concept of saving links effectively useless.
For iOS, use Toolbox Pro for Shortcuts and search for or create a Safari to Markdown file stored in the PKM's inbox. (Or Orion browser with extensions.)
I was considering this when building my own link saver but copyright is so tricky.
On one hand: when you load an URL the contents are already loaded (copied) into your device (browser).
On the other: doing it intentionally is not legal, if you don't have the Right to make a Copy.
Tricky stuff. I was considering making the place you save the contents private but then again when you provide this kind of tool you could get in trouble.
Would like to hear what others think about this.
Maybe naming it "archive"? I understand that's how archive.org gets away with it.
I don't see how it can be a copyright problem to allow people to save it privately. Especially since every copy is deliberate, i.e user chosen to save that particular page.
It can be. Providing the tool to do something illegal, with the sole purpose of the tool being to do something illegal, is illegal. Check out the YouTube DL project history/controversy.
Browsers provide the tool to save those pages (ctrl+s), in what way is it different? Honest question, as I'm building something that could be impacted.
I think this is important. There’s no way I’m going extended permissions to a rando app. Even just giving permissions to a single repo is tricky given the GitHub signin.
I’d rather just grant permissions to a particular user to write to my link-book repo. I think it’s more accurate anyway as it’s link-book writing stuff, not me.
I don't quite understand what the intended flow is in this application, but this reminds me of something similar that I've been meaning to implement myself:
I'm thinking of a system that would allow me to 'ingest' browser bookmarks into git, at the precise time they were created/updated. This will allow me to use Chrome's 'native' sync to update/access my bookmarks from a number of devices; when I'm back at my stationary computer (or at a fixed time interval) a script can update a git repository according to the changes I made. Chrome knows when each individual bookmark was updated, and so my script would be able to set the appropriate git commit time.
Setting a precise git commit time (I want not only the date I updated the bookmark, but the time too) is important to me as a consequence of the following two facts:
* I like having a history of my actions so that I can find out more details about what I was doing at the time, using tools such as Google Activity and bash history.
* I don't want to have to perform some preliminary action (such as running git pull) before I can view my recently added bookmarks.
I already use a similar system for note-taking, with Syncthing as the sync mechanism and a small script for commiting a file at the time it was modified (perhaps on a different device).
Thanks! that is the great thing about feedback ha ha. Obviously the HN crowd are going to be more wary of this.
But even if they weren't, in general you want to assume you will be hacked, and then based what permissions you ask for based on that assumption. I.e. be secure, and use principle of least priveledge, even if the users don't care. This is why I try to get out of having admin permissions to things at work :-) </rant>
A lot of IoT security problems has that combo of vendor and consumer both not caring/understanding/being aware of security issues.
Only asking for repo:public_repo should solve for the "I'm not giving you private repo access" concern. (I'm not, either! Nothing personal, but if that stuff was ready for prime time it wouldn't be private.)
The "fine-grained token" beta is what you really want to use if you can, because that does give single-repository access, which classic Github OAuth tokens do not. No idea how or if it's possible yet to use that type of token in your grant flow, but that's where you probably want to be looking.
thanks for the details - I was looking at the fine grained token but the user would then have to provide me with the the token and then I'd have to store that on my end - since i'm trying to avoid storing any user data that doesn't really play into the structure at all
with regards to the public token thing it's a bit of the same complexity since I would need to know if the repository the user is using is public or private and then configure the OAuth scopes appropriately since I do want to have support for private repos (as that's how I use it currently)
You could keep a fine-grained token in local storage, maybe. Bit of a headache for multiple device/browser use, but I guess that's the tradeoff - lose adoption to mistrust due to Github making you request overbroad permissions with a classic token, or lose adoption to friction due to Github not yet making fine-grained tokens available in their OAuth grant flow.
It might get easier once fine-grained tokens leave beta. I don't know if OAuth support is on the roadmap for that, but it seems like a natural enough fit I'd be astonished if it weren't.
thanks for all the feedback everyone, i've made an update that makes it possible to only give access to a single repository instead of the entire account