Support requesting Wayback Machine to capture page on bookmark add

[michaelmior]

It would be great if it were possible to have buku automatically request that the Wayback Machine archive a page when a new bookmark is added. I've had it happen before that I bookmark something, the page goes away, and no one else has saved it. The API documentation seems like this would be a fairly straightforward integration, although unlike the current integration for viewing captures, there would be a need for a way to provide API access keys.

[michaelmior]

Actually, it looks like LinkAce saves pages without requiring authentication.

[stites]

Making this a little more concrete, we would need the following:

• add a new optional column to the database (similar to the url w/o redirects) in add_rec.
• add a new function archive_request that performs the request documented above in LinkAce (I think we can just reference archivenow's IA handler in python. Alternatively: depend on archivenow.
• add a command line argument for opt-in behavior (these requests can be slow slow)
• sprinkle the new behavior around.

I think this is a small feature that touches a lot of code -- would a pullrequest like this be accepted? A hack to get "archives + buku" could just wrap buku with archivenow, but a buku archiving feature would make buku more reliable and a source of truth for all bookmarks.

[jarun]

add a new optional column to the database (similar to the url w/o redirects) in add_rec

Why would it need to make its way into the DB? I would prefer to keep it an option, which if used, would send the request. No information is required to be stored in the DB.

[LeXofLeviafan]

I think this is a small feature that touches a lot of code

I'm not sure if it's a good idea to implement a feature like that (which to be honest not that many users would really care for) by overhauling the entire codebase… May I suggest waiting for the customization features I've been planning to implement after the next version release? At that point it should be possible to implement such functionality as an (external) plugin.

[LeXofLeviafan]

A hack to get "archives + buku" could just wrap buku with archivenow, but a buku archiving feature would make buku more reliable and a source of truth for all bookmarks.

You could try doing this as a temporary solution though :thinking:

[stites]

Why would it need to make its way into the DB? I would prefer to keep it an option, which if used, would send the request. No information is required to be stored in the DB.

I think implementing this as a feature of buku would warrant this information getting added to the DB. The motivation would then be that "buku would always have a permalink that doesn't suffer from bitrot" (the usual motivation for archiving).

I'm not sure if it's a good idea to implement a feature like that (which to be honest not that many users would really care for) by overhauling the entire codebase…

: ) exactly why I asked (although the codebase seems very managable -- kudos!). Technically it also opens up a whole can of worms regarding archiving design decisions.

May I suggest waiting for the customization features I've been planning to implement after the next version release? At that point it should be possible to implement such functionality as an (external) plugin.

This is exactly what I was hoping for!

A hack to get "archives + buku" could just wrap buku with archivenow, but a buku archiving feature would make buku more reliable and a source of truth for all bookmarks.

You could try doing this as a temporary solution though 🤔

:+1: this was sort of what I was expecting : )

Is there a ticket to track plugin support?

[LeXofLeviafan]

Is there a ticket to track plugin support?

I don't believe I've created one yet. I might likely open a discussion regarding the feature draft before that; you'll probably want to participate in that one :thinking:

Before that, though, I'm still working on #753 for the next version (we're preparing for the upcoming major flask-admin release).