Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1476 closed enhancement (invalid)

Bote P2P update mechanism

Reported by: user Owned by:
Priority: maintenance Milestone: undecided
Component: apps/plugins Version: 0.9.17
Keywords: I2P-Bote, updater Cc:
Parent Tickets:

Description

While checking for updates from the eepsite is secure as it is authenticated, it depends on the eepsite being up in the momentt of checking.

It would be desireable not to depend on that at all, and rather get a valid new version from any peer that has it. A valid version is one signed by a trusted developper. this need not even be only one. That way, you can install HH's Bote releases or str4ds without having to insinstall.

A trusted Bote dev could release a a new version by simply giving it a higher version number (to prevent abuse it could even be limited to version= timestamp in unixtime), signing it, and deploying it on one router.

  • Each bote node advertises the version it has, the hash of the update file as a signed record of versionNumber + " " +fileHash + " " + trustedSigner.
  • Each bote node upon receiving an announce from a connected peer checks validity:

if (advertised_timestamp > local_timestamp &&

advertised_timestamp < current_time &&
is_truster(signer) && isAuthentic(record,signer) {

updateFile = getUpdateFile_from_peer();
int i = record.indexOf(" ");
verifiedFileHash = record.substring(i+1, i+1+hashLength);
if (somechecksum(updateFile).equals(verifiedFileHash)) {

installUpdate(updateFile);

}

}

Subtickets

Change History (8)

comment:1 Changed 4 years ago by rhoze

This is a great idea. I would just add that it should definitely provide an option to only install the new version if the user authorizes it.

comment:2 Changed 4 years ago by str4d

  • Resolution set to invalid
  • Status changed from new to closed

Firstly: I2P-Bote will not perform visible update checks any longer from the next release. HungryHobo removed that functionality shortly after releasing 0.2.10 (in 1061947df94a8b558fd512b3ff5ef0d896cbf871), because the I2P plugin system has now implemented auto-updating for some time.

Secondly: this is not something that should be implemented in I2P-Bote; if anywhere, it would belong in the I2P plugin update mechanism, as a general method of updating plugins. If you want to suggest this as an enhancement, please open a new ticket.

comment:3 follow-up: Changed 4 years ago by user

  • Keywords I2P-Bote added
  • Resolution invalid deleted
  • Status changed from closed to reopened

firstly, afaik the update search done by router also only checks the eepsite for available updates. i think this would be an improvement. and just that is currently is done by router's plugin system is not a reason it could not be handled more flexibly with current machnism as a fallback

secondly, how would e.g. zzzot nstances know the destainaion of other zzzot instances to download update from? i don't se how this could be generic for al plugins.

ps: the record should also contain an entry about required min router version

comment:4 in reply to: ↑ 3 ; follow-up: Changed 4 years ago by str4d

Replying to user:

firstly, afaik the update search done by router also only checks the eepsite for available updates. i think this would be an improvement. and just that is currently is done by router's plugin system is not a reason it could not be handled more flexibly with current machnism as a fallback

It could be handled more flexibly by the router, I agree. But that deserves a new ticket, not a continuation of this one, for reasons outlined below.

secondly, how would e.g. zzzot nstances know the destainaion of other zzzot instances to download update from? i don't se how this could be generic for al plugins.

There are two separate issues here: how to notify the router of updates to a particular plugin, and how to download the updates.

P2P downloading is simple, you would use torrents. The router update mechanism has the backend mechanics to support this, it would simply need extension to enable plugins to also be updated via torrents. This would greatly improve the accessibility of updates, as they would no longer be reliant on any particular eepsite.

Notifying the router of new updates is the "hard" part. I2P updates are notified through the news feeds, which makes router updates reliant on a few central services. Plugin updates are currently notified through the downloads themselves, so after moving to torrents there would still need to be some URL operated by the plugin maintainer that would provide notifications. An alternative could be that plugin updates need to be registered on plugins.i2p, in the same way that Python library updates are posted on PyPI.

Now, maybe there could be some way inside I2P-Bote to distribute the latest version amongst all nodes. But I am dubious about this - what about Bote for Android? What about a future implementation in another language? Why should we add a completely new network packet or mechanism specifically to cater for a single type of I2P-Bote client? And even if it was added, we would still need a way for the I2P-Bote plugin to inform the router of the new update, which implies a change to the I2P plugin spec.

So to summarize, the only part of the original request that might be relevant is some "current version" packet in the I2P-Bote DHT. Everything else I consider invalid in the context of I2P-Bote alone. I think there are good ideas here, but they need to be reworked into a new ticket as an enhancement to the I2P plugins API and update system.

ps: the record should also contain an entry about required min router version

The plugin.config for each plugin already supports this IIRC.

Last edited 4 years ago by str4d (previous) (diff)

comment:5 Changed 4 years ago by str4d

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:6 Changed 4 years ago by user

this thing would be almost trivial to implement.
your issue about different implementations could be easily handled with one additional field in the announce record, that has a unique identifier like 'boteandroidstr4d-forkbyfoo'.

The only remaining issue would be how to inform router about the update.

comment:7 Changed 4 years ago by user

and while I am aware that we bundle i2psnark, what about some versions that in the futere might not bundle i2psnark anymore? if they get their i2p updates via package manager ...
this approach here would be autark and not depend on any external update machanisms or torrent clients to be bundled. Nor is this ticket about implementing bittorrent in Bote. I simply point to point transfer suffices, as it already is distributed it would not have a central node getting overloaded.

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

Replying to str4d:

P2P downloading is simple, you would use torrents.

You can do that. I suggested direct downloads in order to keep complexity and dependencies low.

Notifying the router of new updates is the "hard" part. I2P updates are notified through the news feeds, which makes router updates reliant on a few central services.

I don't think news feeds should have to be bothered with announcing new versions of plugins. They could advertise them as in making them known to the users, but that is about PR/marketing, not the update process. Updates should be as self-contained as possible, and "just work"

Plugin updates are currently notified through the downloads themselves, so after moving to torrents there would still need to be some URL operated by the plugin maintainer that would provide notifications. An alternative could be that plugin updates need to be registered on plugins.i2p, in the same way that Python library updates are posted on PyPI.

Main dev goes awol, his eepsite becomes unreachable. updates are broken.
Uninstalling and reinstalling from another developer's eepsite is cumbersome.
Adding a new trusted signer via the GUI is easy. The update mechanism takes care of the rest.
If it finds an update, the user is prompted to answer if he wants to download it or not.

But I am dubious about this - what about Bote for Android? What about a future implementation in another language? Why should we add a completely new network packet or mechanism specifically to cater for a single type of I2P-Bote client?

see comment 7.

And even if it was added, we would still need a way for the I2P-Bote plugin to inform the router of the new update, which implies a change to the I2P plugin spec.

This is the only real issue with it. I understand that changing the spec just to cater for one plugin is not wanted. Maybe a downloaded plugin could be automatically installed upon router restart, just like with router updates. This would not be very Bote-specific and also not too invasive.


So to summarize, the only part of the original request that might be relevant is some "current version" packet in the I2P-Bote DHT....

and

I think there are good ideas here.

Basically it was just the idea of p2p advertizing, checking, and then getting it from the peer. But "might" be relevant sounds rather sceptic, so it seems you do not consider the ideas to be "good"

Note: See TracTickets for help on using tickets.