Beaker: Feature: Add "Make editable copy" to legacy https / http pages as well.

[Gozala]

On multiple occasions I found myself using "Save Page As..." feature (in Firefox, one in beaker doesn't seems to work) and then adding saved page (dir containing all the assets) to beaker library.

It is was useful in one instance as it allowed me to share meetup schedule where internet connectivity was spotty. On other instances I just wanted to pin down the page for later consumption.

I think beaker has opportunity to allow capturing arbitrary pages into library if it were to combine contents.savePage Electron API with starting a new archive feature.

Would be even more cool to expand support for this to DatArchive.fork to let apps do more interesting things with it.

This has come up in dat://fritter.hashbase.io/thread/dat://453c8faa21215ad8da5970ecce16474515d298963953e733b4520c25992ee906/posts/0jmthmg6m.json

[pfrazee]

Yeah that's a cool idea. If somebody wants to implement this, I'm +1 to adding it.

[Gozala]

I might take a stab if I'll find a time to do so.

@pfrazee which ideal did you 👍 btw, there are two

1. Extend DatArchive.fork API to allow creating editable copies of a page via API.
2. Have a "make editable copy" button on http(s) sites as well.

If I were to work on this I'd prefer to start with 1 as it involves no UI & enables interesting applications. Once that's in place I'd tackle 2 which pretty much would just expose functionality through UI.

[pfrazee]

Only the latter (number 2). This feature requires HTML-centric parsing and resource crawling which I dont think fits in DatArchive

[brechtcs]

I'm not a lawyer myself, but I worry whether this feature might lead to some legal problems down the road.

Basically, when someone publishes a site through dat they are (or should be) aware that it's trivial to clone/fork their contents, because that's inherently how the protocol they've chosen works. So you can make the case that any publisher using dat has consciously opted into these features.

With HTTP that's not the case. And while it might be possible to support dat-like behaviour for HTTP sites, that's not something users of the HTTP protocol should reasonably expect. Therefore publishers using HTTP might blame Beaker for allowing people to gather and reuse their content in ways that they never agreed with.

At least that's my worry. An actual lawyer might be able to judge how valid a concern this really is.

[Gozala]

Only the latter (number 2). This feature requires HTML-centric parsing and resource crawling which I dont think fits in DatArchive

That's actually all handled by a contents.savePage, meaning it will create a directory with all files and links rewired to match local files.

[Gozala]

I'm not a lawyer myself, but I worry whether this feature might lead to some legal problems down the road.

Basically, when someone publishes a site through dat they are (or should be) aware that it's trivial to clone/fork their contents, because that's inherently how the protocol they've chosen works. So you can make the case that any publisher using dat has consciously opted into these features.

With HTTP that's not the case. And while it might be possible to support dat-like behaviour for HTTP sites, that's not something users of the HTTP protocol should reasonably expect. Therefore publishers using HTTP might blame Beaker for allowing people to gather and reuse their content in ways that they never agreed with.

At least that's my worry. An actual lawyer might be able to judge how valid a concern this really is.

I have no idea if that could be an issue. What I do know is that it's fairly easy, it just requires two actions:

1. Save Page As
2. Create New Site From Folder

Proposal here just collapses those two into Create Site From Page or something along those lines.

I would expect that legal actions could be targeted at individuals who choose to distributed copyrighted content that way. Also not a lawyer so this just a speculation.

[pfrazee]

@brechtcs Actually I do think that's a fair concern. We've been planning to add copy controls and licensing to dats specifically for authors to voice their wishes on forkability.

[brechtcs]

Right, I think with this kind of controls in place there would still be three scenarios:

1. the site owner explicitly allows copying => show fork option in the UI
2. the site owner explicitly forbids copying => don't show fork option in UI
3. the site owner hasn't specify whether copying is allowed => display fork option, but show a "this might be illegal, use at your own responsibility" warning to users before proceeding

I guess having HTTP sites automatically fall into the third category would be alright then.

It's a fine line though between a tool that can be used for copyright infringement (i.e. any browser) vs. a tool that's designed for copyright infringement (i.e. Napster and friends). Especially in the light of recent legal changes in the EU, it's probably best to thread carefully.

[pfrazee]

@brechtcs yeah, plus it's the right thing to do. We should encourage permissive licensing but sometimes people just don't want their work copied! An example being your personal website for instance.

[Gozala]

This exchange got me to rethink the premise. I think it worth iterating goals vs describing a specific solution as I did in this issue. Here are few motivations:

1. Save / organize discovery so it can be revisited in a future.
2. Share a discovery with someone.
3. Annotate or incorporate a discovery.

[User research] done by Mozilla suggests that people are aware of link rot issue and don't trust bookmarks as a mechanism to save / organize:

• Bookmarked link may no longer be reachable later.
• Content may be totally different on next visit.

So people often resort to screenshots to overcome this limitation.

Study also showed us that people also rarely use links for sharing because:

• Link rot (Content may no longer be available or be different by the time receiver visits it)
• Receiver may not see the same thing due to geo-location or page being behind session, etc...
  
  
  
  • Links lack a context - Page may or may not have anchor to a relevant segment & even that may not be enough and additional note could make a huge difference.
  
  

So again people often resort to screenshots and more tech savvy ones sometimes incorporate picture editing apps for annotation purposes.

This was at a scale that Mozilla implemented Firefox screenshots feature that pretty much does that lets you save a screenshot of a region or a full page (even parts below veiwport), optionally annotate upload it online so you can share it with others.
_I am certain that legal aspect of this has being thoroughly considered as it is part of process of shipping things at Mozilla._

With that said there is still a huge limitation to Screenshots, that is you can't interact with it, can't even select a text. So what I was aiming here is to overcome that limitation & hopefully allow collaboration with individual you shared captured content similar to http://hypothes.is/

All this suggests me that I don't actually want forking, but I want saving + annotating / incorporating + sharing. So maybe there is an alternative way to presenting this. Maybe instead of creating editable copy you could just have "save a copy" with a pointer in dat.json to an original that beaker than could display such dat's as a "reshare" (as in retweet) or as an "incorporation" (annotation or a fragment) of the "original".

[Gozala]

I think there are still few cases & reasons why publishers may want to prevent you from copying + sharing with others:

1. Things that are behind paywall. They want consumers to pay and referencing origin does not really address this.
2. Sites that depend on add traffic would likely want to get visitors on their page rather than on a copy referencing them.

So yeah probably copy controls are more productive way to go about it. We could also possibly have something along the lines of robots.txt that would direct beaker what can & can not be saved with a page.

[pfrazee]

It sounds like what you’re describing is a “snapshot” feature.

[julianpistorius]

Maybe duplicate of: https://github.com/beakerbrowser/beaker/issues/1005