Opened 3 years ago

Last modified 2 years ago

#1660 assigned enhancement

I2P-Bote: p2p plugin update

Reported by: user Owned by: str4d
Priority: minor Milestone: eventually
Component: apps/plugins Version: 0.9.22
Keywords: Cc:
Parent Tickets:

Description

Just like I2P router updates via torrents now, it would be nice if plugins could be updated in a p2p fashion too.

Checking a central eepsite for updates is not optimal. It could be down in the very moment of checking, or down for good.
As long as the plugin is still being developped and the plugin's network is intact, i.e. there are users using it, why not use those to propagate the update? Originally I proposed this as an enhancement to Bote ( #1476 ), but I was told there should rather be improvement to the general mechanism for all plugins.

Ideally use the plugin's own tunnels for that. If the plugin is something entirely tunnelless, maybe use http proxy or create one temporary tunnel pair.

So peers running the plugin exchange messages about hteir current versions.
If a peer reports a version higher than ours of a plugin we have, check if it is signed by a trusted signer, if so, request the update.

Info to be included:
plugin name (e.g. Bote, BoteAndroid?, BoteForkXYZ-Android) - a string,
version, or better timestamp,
signer,
signature.

There should be a list of trusted signers per plugin - easily editable via webui.
With two options: allow signers list to be remotely update, or not.
If it is updateable, the current maintainer can add a new developer that he trusts, and users will accept his updates too. So once the original developer leaves, users will not have to change a thing but will still get updates, provided that there was a smooth transition. When a new trusted signer is added, the user will be notified

Subtickets (add)

Change History (4)

comment:1 Changed 3 years ago by zzz

#1476 is interesting reading.

As str4d commented on that ticket, the hard part is notification of a new version. Either latest plugin version and infohash are in the main news feed, or there's some sort of signed notification inside bote itself that's distributed somehow in bote-bote communication.

The former uses the router's update subsystem... the latter is bote-specific.

comment:2 Changed 3 years ago by user

I don'think it should be in the news feed. Should it?
I mean they are not part of i2p propper.

And Bote already has a p2p networ where it exchanges information (e.g. they do exchange peer infos, so that peer info propagates thorough the net and they connect better)

So what I had in mind was Bote-internal only.
It would require a curr_version or simply infomsg message that hold at least this info:

[
 pluginname (e.g. i2pbote_C++_by_cppcoder_arm)
 plugin version: e.g. 0.4.1 (just for info)
 type: bin or src (so even source code can be distributed this way)
 date (this is what is checked, it is the date, the update was signed by its dev, must be newer than current one and less than curent time to be eligible for download)
 file-hash
 signer-key
 optionally: list of other trusted signers trusted by current signers (plus which current dev trusts, plus signature of that dev, so a lil string[5][] array: name, pk, name, pk, sig
]
signature

I think, four message types would suffice:
infomsg, get_infomsg, get_update, update

it should use the plugin's OWN tunnels.

notification of a new version:
simply get such a infomsg from a peer, check if it is interesting (date, name), if yes, check if trusted singer, if yes, check signature.

The news feed is something more or less centralized too.
With the above, it is totally decentralized. all you need is the pk of a dev you trust and decide if you want to trust the other devs this dev trusts (you'd always get a notification about additional devs, and must confirm adding them to the list of trusted).

Once the plugin is downloaded it should put it into a place where the router recognizes there is an update, and notify the user, and, according to prefs, automatically restart after a rnadom wait time, or wait for the user to restart the router (or if no router restart necessary, then only restart plugin)

There was concern that this would be a system that would only work for one certain type of bote, i.e. for example not for android.
But unless android apps cannot download updates on their own, it should work with that just as well.

Now, str4d said it should not be inside Bote but general.
But as I said, I think the news feed is mainly for i2p router, not for plugins.
(router updates, maybe general interest i2p news, which could also tell about new plugins or so, but it is more centralized.)

My issue is that not every plugin does networking, i.e. though it may have its own tunnels (if not, if it uses eepProxy, then of course update can use it too), it may not know any other instance of the plugin running.

Last edited 3 years ago by user (previous) (diff)

comment:3 follow-up: Changed 2 years ago by zzz

  • Owner set to str4d
  • Status changed from new to assigned
  • Summary changed from p2p plugin update to I2P-Bote: p2p plugin update

As the comment above clarifies, this proposal is for Bote only. Adding I2P-Bote to the title and assigning to str4d.

As there's no facility in the router for a plugin to update itself (can't stomp on your own classpath), this sounds very difficult. Sponge, years ago, advocated for a staging system (similar to the way i2pupdate.zip works, where new plugin versions would be stored in zip form and installed at router startup). I resisted as it sounded like it was more trouble than it's worth.

Even if it is stored in the DHT at a "known place", how do you trust the bote at that place to serve the actual latest version? Or for any bote to know what the latest version is? Another tricky problem.

Up to str4d if he wants to leave this open or close won't-fix.

comment:4 in reply to: ↑ 3 Changed 2 years ago by user

Replying to zzz:

As there's no facility in the router for a plugin to update itself (can't stomp on your own classpath), this sounds very difficult. Sponge, years ago, advocated for a staging system (similar to the way i2pupdate.zip works, where new plugin versions would be stored in zip form and installed at router startup). I resisted as it sounded like it was more trouble than it's worth.

I thought it could just do the same that manually clicking "update" in the console does.

Even if it is stored in the DHT at a "known place",

The original idea was not even to store it in the DHT, but directly on each using client. So the bote nodes you are directly connected to, tell you the version they have.

… how do you trust the bote at that place to serve the actual latest version? Or for any bote to know what the latest version is? Another tricky problem.

If theirs (versionnumber or release date) is newer than ours, update or notify the user, depending on the settings. If you want to account for different versions being run on neigboring nodes, discard all that are <= our own, and from the remaining, pick the very latest.
That it is legit is verified by the signature of one of the devs listed in the plugin config's list of trusted devs. If a new dev appears and is trusted by the user, he can add his key.
That means before any actual update is being downloaded, both version and signature are checked (what is signed is the version number or release date and the update file's description and the update file's infohash, all covered by one signature and bundled with that signature into one message of defined max_length.
After download of the actual plugin update, this is checked for integrity using at least the infohash, maybe also a signature, before it is being installed, if user has set automatic installation, otherwise the user is just notified about the availability of that update.

If you set no publishable version in your bote, nothing is published and you can experiment with your own builds.
As soon as you set a publishable version and sign it and run it, it will advertize itself to other nodes and if you are a trusted dev, your plugin begins spreading to those who trust you.

Note: See TracTickets for help on using tickets.