Beaker: Discussion: Asking user to seed dats programmatically

[RangerMauve]

Some Dats will contain apps that rely on other data-only dats for all of their important info.

For example, a social media app would rely on the feeds of other people in order to function and it might want to prompt the browser to seed those feeds so you can A: stay up to date, and B: have an altruistic network where peers keep each others data alive when one of them is down (a la SSB).

Would an API for something like this be easy enough to use for people? Would this just open the doors for spammy pages (like the "x wants to access your location" prompt)? Maybe it auto-reject unless the user already decided to seed that dat on their own?

The API could look like DatArchive.requestSeed(url) => Promise

[pfrazee]

Thanks for filing @RangerMauve. This is requested fairly often. See #976 for some additional discussion on this.

[pfrazee]

Ok, here's the labs API I'm looking at right now:

experimental.library.add(url, {duration}) // duration is optional, number of minutes to keep saved
experimental.library.remove(url)
experimental.library.get(url) // returns the settings for the archive
experminetal.library.list({
  inMemory: true/false, // only give dats that are actively swarming
  isSaved: true/false, // only give dats that are saved (exclude the trash) or not (trash only)
  isNetworked: true/false, // only give dats that are networked (no offline) or not (no online)
  isOwner: true/false // only give dats that the user owns or not
})
// events:
// 'added' - archive added
// 'removed' - archive removed
// 'folder-synced' - archive synced to its folder
// 'updated' - archive metadata recently changed
// 'network-changed' - archive peer count recently changed

It's actually more than @RangerMauve suggested, as it includes a lot of facilities to manage the library.

[RangerMauve]

That's awesome! And I'll just need to modify my dat.json for this (once it's out)?

[pfrazee]

Yep, and users will have to grant permission

[pfrazee]

Ok the experimental.library API has been committed to master, per the spec above. To enable it in your application, be sure to include this in the dat.json:

{
  "experimental": {"apis": ["library"]}
}

[pfrazee]

Re-opening because it occurs to me the permissions are problematically broad on this setup. I'd like to have a middle ground, where apps can request to add/remove unowned dats, without being given total control over my library. So, I'm thinking about two new methods, which don't give permanent permissions but ask on every action:

experimental.library.requestAdd(url, {duration})
experimental.library.requestRemove(url)

They will both work like their matching .add() and .remove() but prompt the user every time.

[pfrazee]

Ok, added requestAdd() and requestRemove() as well. They only work on unowned archives, and prompt the user every time. Theyre safer to use as a result.

[RangerMauve]

What do you think about only allowing the API if the dat has already been pinned? This will prevent spam from apps that the user will probably never want access to pinning in the first place?

[pfrazee]

You'd be kind of using "pinned" as a standin for "installed" which I think is an interesting idea but might not fit the UX of pinned. We may actually just create an "app" concept so that installing is explicit.

[RangerMauve]

Yeah, installed is a better word for what I'm thinking of. Basically, I don't think all apps should be treated equally with regards to persistance. I don't know about you, but I'm tired of every single blog or news article trying to get my location and enable push notifications.

Would "bookmark/pin" be the equivalent of "install"?

[pfrazee]

Yeah I totally agree about push notifications. My god, those people.

I think the idea of "install" would be to handle permissions in general, possibly have install effects (like registering the app in an 'intent' system), and save the app for offline. We have some disabled code for this, based on an early idea of apps that we decided to move away from. Once we know better what installation should do, I think we'll readd it.

[RangerMauve]

Awesome! I'll play around with the new APIs and plan for them to error out. :D

[pfrazee]

🤓 sounds good