@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+not_bob
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest75862
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
plap
poriori
profetikla
r3med1tz
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
zzz
eyedeekay, thanks for the two MR reviews last week, but please don't stop, that's not all of them
zzz
eyedeekay, re: roadmap item 'plugin update via torrent'
zzz
you have a writeup or proposal on how that would work?
zzz
if so, we should review; if not, seems unlikely for the next release. I don't think we have all the pieces atm to implement it easily.
eyedeekay
Ack I'll do the other 3 of them today, just got some more to say about the one about the OBEP
zzz
thanks eyedeekay
zzz
and your thoughts on plugin torrents? I see sadie is pimping blizzard this morning...
eyedeekay
I think you might be right about 2.6.0 and plugin torrents, I have a way of doing it that I experimented with in i2p.plugins.firefox but it's turned into a bit of a hackjob
eyedeekay
Blizzard probably doesn't need a torrent as bad as some of the others
eyedeekay
i2p.plugins.firefox rarely updates over I2P successfully because it's fairly huge, it's where my main interest in such a feature comes from
zzz
what I'm getting at is...
zzz
update subsystem is generic, but how would clients authoritatively discover versions/infohashes?
dr|z3d
per-plugin news.xml feed?
zzz
seems like anything you have in mind would be a new spec or an update to an existing one
eyedeekay
Right now how I'm doing it is looking for a torrent on the server right next to the su3 itself, so if there's i2p.plugins.firefox.su3 and it sees that there's also i2p.plugins.firefox.su3.torrent, it downloads the torrent first, adds the http address of the regular su3 as a web seed, and downloads it
zzz
-> doc or proposal, -> no way to implement of 2.6.0 unless you have it at the ready to spring on us
eyedeekay
But notifying the update subsystem that it's downloaded was a problem, and what I just described^above I now consider a hackjob
eyedeekay
Yeah
eyedeekay
dr|zed probably something like that
eyedeekay
Not in it's current form
zzz
feeds per-plugin, or per-author, or add to the main news feed, there are tradeoffs and policy issues
zzz
a .torrent file doesn't have a version number in it, which is problematic
dr|z3d
that can be addressed with a _version_string at the end of the torrent name, assuming the update path is secure.
zzz
messy and not signed/authenticated
dr|z3d
or it could have something added to the metainfo, perhaps?
eyedeekay
zzz's right, right now there's a lot of precise "the torrent must be of exactly this form and exactly this path" stuff to make the hackjob work
zzz
nonstandard drz
dr|z3d
ok
eyedeekay
No version, no way to check the version until after the download is done
zzz
if an authoritative list goes in the main feed then that solves the plugin discoverability problem, at least for plugins we deem worthy, but that somewhat contradicts our original ethos
dr|z3d
this all seems a bit non-standard tbh, so something signed in the metainfo might be the way to go, or just a version suffix on the torrent name, if the update path is secure. I get the impression standards are about to be extended/reforged/mangled :)
dr|z3d
the question I'm asking myself is, is it worth the hassle, when most plugins work fine with the current system.
zzz
the proper way to discover authoritative version and sources is with a signed feed.
zzz
the current method of getting the first 56 bytes dates back to the .sud format that we carefully preserved in .su3
dr|z3d
sure, that's the news.xml per-plugin, presumably, or as you're suggesting as an alternative, per-author.
zzz
we should not attempt to port that hack to torrent files
eyedeekay
Personally I don't like putting them in the main feed, IMO that seems like a barrier which would annoy me if I didn't sign the feeds
eyedeekay
Agreed
eyedeekay
IMO signed feed per-plugin is intuitive, but per-author(or is it "per-set of plugin keys") intrigues me, I hadn't considered it yet
zzz
anyway that's your obstacle. The update subsystem itself is generic, extensible, and able to handle anything you can define
zzz
I suggest you write it up and get consensus before putting it on the roadmap though
eyedeekay
OK
dr|z3d
here, kytv, so your plugins site doesn't look like a refugee from 2014: cake.i2p/file/0lIVtYbs8S_Jx2qcsraZ6Y9wgNYspGK2Vvjb7JG1M_jijO13h1xb/plugins-i2p.zip