forked from I2P_Developers/i2p.www
Replace all references to eepSite with I2P Site
This commit is contained in:
@@ -14,8 +14,8 @@ great job of upgrading - we only have two holdouts now (one
|
||||
at 0.3.2.2 and one way back at 0.3.1.4 :). Over the last
|
||||
few days the network has been more reliable than usual -
|
||||
people are staying on irc.duck.i2p for hours at a time,
|
||||
larger file downloads are succeeding from eepsites, and
|
||||
general eepsite reachability is fairly good. Since its
|
||||
larger file downloads are succeeding from I2P sites, and
|
||||
general I2P site reachability is fairly good. Since its
|
||||
going well and I want to keep you on your toes, I decided
|
||||
to change a few fundamental concepts and we'll have them
|
||||
deployed in a 0.3.3 release in a day or two.
|
||||
@@ -86,7 +86,7 @@ to jump on -
|
||||
news be a simple heading, with an announcements page
|
||||
below?
|
||||
* i2ptunnel_services, i2ptunnel_tuning, i2ptunnel_lan:
|
||||
We need someone to rewrite the 'how to set up an eepsite'
|
||||
We need someone to rewrite the 'how to set up an I2P site'
|
||||
page, as well as include answers to the two most
|
||||
frequently asked I2PTunnel questions (how to access it
|
||||
through a LAN and how to configure its tunnels - answers
|
||||
|
@@ -15,7 +15,7 @@ hi y'all, lets get this status update out of the way
|
||||
|
||||
With last week's 0.3.4 release, the new net is performing pretty
|
||||
well - irc connections are lasting for several hours at a time and
|
||||
eepsite retrieval seems to be pretty reliable. Throughput is
|
||||
I2P site retrieval seems to be pretty reliable. Throughput is
|
||||
still generally low, though slightly improved (I used to see a
|
||||
consistent 4-5KBps, now I consistently see a 5-8KBps). oOo has
|
||||
posted up a pair of scripts summarizing the irc activity,
|
||||
|
@@ -14,7 +14,7 @@ Hey everyone, weekly update time
|
||||
Well, we've pushed out the 0.3.4.1 release the other day, and it has
|
||||
been doing pretty well. Connect times on irc have been consistently
|
||||
for multiple hours, and transfer rates are doing pretty good as well
|
||||
(I pulled 25KBps from one eepsite the other day using 3 parallel
|
||||
(I pulled 25KBps from one I2P site the other day using 3 parallel
|
||||
streams).
|
||||
|
||||
One really cool feature added in with the 0.3.4.1 release (that I
|
||||
|
@@ -23,7 +23,7 @@ pretty well since. There have been some problems with some newly
|
||||
introduced tunnel testing and peer selection code, but after some
|
||||
tweaking since the release, its pretty solid. I don't know if the
|
||||
irc server is on the new rev yet, so we generally have to rely on
|
||||
testing with eepsites and the http outproxies (squid.i2p and
|
||||
testing with I2P sites and the http outproxies (squid.i2p and
|
||||
www1.squid.i2p). Large (>5MB) file transfers in the 0.3.4.3
|
||||
release are still not reliable enough, but in my testing, the
|
||||
modifications since then have improved things further.
|
||||
@@ -125,12 +125,12 @@ let the new jcpuid code choose the right one).
|
||||
* 2.3) i2paddresshelper
|
||||
|
||||
oOo has put together a really cool helper to let people browse
|
||||
eepsites without updating their hosts.txt. It is committed to CVS
|
||||
I2P sites without updating their hosts.txt. It is committed to CVS
|
||||
and will be deployed in the next release, but people may want to
|
||||
consider updating links accordingly (cervantes has updated
|
||||
forum.i2p's [i2p] bbcode to support it with a "Try it [i2p]" link).
|
||||
|
||||
Basically you just make a link to the eepsite with whatever name you
|
||||
Basically you just make a link to the I2P site with whatever name you
|
||||
want, then tack on a special url parameter specifying the
|
||||
destination:
|
||||
|
||||
@@ -138,7 +138,7 @@ destination:
|
||||
|
||||
Behind the scenes, its pretty safe - you can't spoof some other
|
||||
address, and the name is *not* persisted in hosts.txt, but it will
|
||||
let you see images / etc linked to on eepsites that you wouldn't be
|
||||
let you see images / etc linked to on I2P sites that you wouldn't be
|
||||
able to with the old <a rel="nofollow" href="http://i2p/base64/">http://i2p/base64/</a> trick. If you want to always
|
||||
be able to use "wowthisiscool.i2p" to reach that site, you will
|
||||
still of course have to add the entry to your hosts.txt (until the
|
||||
|
@@ -107,11 +107,11 @@ about implementing transparent DCC though, so perhaps the IRC
|
||||
side could be used for public chat and DCC for private file
|
||||
transfers or serverless chat.
|
||||
|
||||
General eepsite functionality is also important, and what we
|
||||
General I2P site functionality is also important, and what we
|
||||
have now is completely unsatisfactory. As DrWoo points out [9],
|
||||
there are significant anonymity risks with the current setup,
|
||||
and even though oOo has made some patches filtering some
|
||||
headers, there is much more work to be done before eepsites can
|
||||
headers, there is much more work to be done before I2P sites can
|
||||
be considered secure. There are a few different approaches to
|
||||
addressing this, all of which can work, but all of which
|
||||
require work. I do know that duck mentioned he had someone
|
||||
@@ -151,9 +151,9 @@ network load. It doesn't, however, offer the full richness of
|
||||
normal websites, but the 1.8 million active LiveJournal users
|
||||
don't seem to mind.
|
||||
|
||||
Beyond that, securing the eepsite architecture would be my
|
||||
Beyond that, securing the I2P site architecture would be my
|
||||
next preference, allowing browsers the safety they need and
|
||||
letting people serve eepsites 'out of the box'.
|
||||
letting people serve I2P sites 'out of the box'.
|
||||
|
||||
File transfer and distributed data storage are also incredibly
|
||||
powerful, but they don't seem to be as community oriented as
|
||||
|
@@ -14,7 +14,7 @@ Hi y'all, its weekly update time
|
||||
|
||||
After a pretty bumpy 0.4.1 release (and subsequent rapid 0.4.1.1
|
||||
update), the net seems to be back to normal - 50-something peers
|
||||
actrive at the moment, and both irc and eepsites are reachable. Most
|
||||
actrive at the moment, and both irc and I2P sites are reachable. Most
|
||||
of the pain was caused by insufficient testing of the new transport
|
||||
outside lab conditions (e.g. sockets breaking at strange times,
|
||||
excessive delays, etc). Next time we need to make changes at that
|
||||
@@ -133,13 +133,13 @@ lib, we'll switch 'em.
|
||||
* 4) Bundled eepserver
|
||||
|
||||
As was mentioned in the 0.4.1 release notes [3], we've bunded the
|
||||
software and configuration necessary for running an eepsite out of
|
||||
the box - you can simply drop a file in the ./eepsite/docroot/
|
||||
software and configuration necessary for running an I2P site out of
|
||||
the box - you can simply drop a file in the ./I2P site/docroot/
|
||||
directory and share the I2P destination found on the router console.
|
||||
|
||||
A few people called me on my zeal for .war files though - most apps
|
||||
unfortunately need a little more work than simply dropping a file in
|
||||
the ./eepsite/webapps/ dir. I've put together a brief tutorial [4]
|
||||
the ./I2P site/webapps/ dir. I've put together a brief tutorial [4]
|
||||
on running the blojsom [5] blogging engine, and you can see what that
|
||||
looks like on detonate's site [6].
|
||||
|
||||
|
@@ -67,11 +67,11 @@ More news when there's more news.
|
||||
|
||||
* 4) files.i2p
|
||||
|
||||
Ok, we've had a lot of new eepsites lately, which is kickass. I just
|
||||
Ok, we've had a lot of new I2P sites lately, which is kickass. I just
|
||||
want to point out this one especially as its got a pretty neat
|
||||
feature for the rest of us. If you haven't been to files.i2p, its
|
||||
basically a google-like search engine, with a cache of the sites it
|
||||
spiders (so you can both search and browse when the eepsite is
|
||||
spiders (so you can both search and browse when the I2P site is
|
||||
offline). v.cool.
|
||||
|
||||
* 5) ???
|
||||
|
@@ -12,7 +12,7 @@ Hi y'all, weekly update time
|
||||
* 1) Net status
|
||||
|
||||
I don't want to jinx it, but for the last week the network has been
|
||||
pretty much as before - fairly stable for irc, eepsites loading
|
||||
pretty much as before - fairly stable for irc, I2P sites loading
|
||||
reliably, though large files still often require resuming. Basically
|
||||
nothing new to report, beyond the fact that there's
|
||||
nothing new to report.
|
||||
|
@@ -13,9 +13,9 @@ Hi y'all, time for the weekly update
|
||||
|
||||
* 1) Net status
|
||||
|
||||
Pretty much as before - a steady number of peers, eepsites fairly
|
||||
Pretty much as before - a steady number of peers, I2P sites fairly
|
||||
reachable, and irc for hours on end. You can get a peek at the
|
||||
reachability of various eepsites through a few different pages:
|
||||
reachability of various I2P sites through a few different pages:
|
||||
- <a rel="nofollow" href="http://gott.i2p/sites.html">http://gott.i2p/sites.html</a>
|
||||
- <a rel="nofollow" href="http://www.baffled.i2p/links.html">http://www.baffled.i2p/links.html</a>
|
||||
- <a rel="nofollow" href="http://thetower.i2p/pings.txt">http://thetower.i2p/pings.txt</a>
|
||||
|
@@ -78,7 +78,7 @@ old lib - I2PTunnel and SAM streams automatically use it, but from
|
||||
a packet perspective, it is *not* backwards compatible. This leaves
|
||||
us with an interesting dilemma - there is nothing within I2P
|
||||
requiring us to make 0.4.2 into a manditory upgrade, however people
|
||||
who don't upgrade won't be able to use I2PTunnel - no eepsites, no
|
||||
who don't upgrade won't be able to use I2PTunnel - no I2P sites, no
|
||||
IRC, no outproxy, no email. I don't want to alienate our long time
|
||||
users by forcing them to upgrade, but I also don't want to alienate
|
||||
them by having everything useful break ;)
|
||||
|
@@ -7,7 +7,7 @@ Hi y'all
|
||||
1) 0.4.2 and 0.4.2.1
|
||||
2) mail.i2p
|
||||
3) i2p-bt
|
||||
4) eepsites
|
||||
4) I2P sites
|
||||
5) ???
|
||||
|
||||
* 1) 0.4.2 and 0.4.2.1
|
||||
@@ -36,10 +36,10 @@ some trouble with the i2p-bt port. Some of the problems have been
|
||||
identified found and fixed in the streaming lib, but further work
|
||||
is necessary to get it where we need it to be.
|
||||
|
||||
* 4) eepsites
|
||||
* 4) I2P sites
|
||||
|
||||
There has been some discussion over the months on the list, in the
|
||||
channel, and on the forum about some problems with how eepsites
|
||||
channel, and on the forum about some problems with how I2P sites
|
||||
and the eepproxy work - recently some have mentioned problems with
|
||||
how and what headers are filtered, others have brought up the
|
||||
dangers of poorly configured browsers, and there's also DrWoo's
|
||||
|
@@ -7,7 +7,7 @@ Ev'nin folks, time for our status update
|
||||
1) 0.4.2.4 & 0.4.2.5
|
||||
2) 0.5 strategy
|
||||
3) naming
|
||||
4) eepsite roundup
|
||||
4) I2P site roundup
|
||||
5) ???
|
||||
|
||||
1) 0.4.2.4 & 0.4.2.5
|
||||
@@ -77,9 +77,9 @@ based manager at <a rel="nofollow" href="http://susi.i2p/susidns/manager">http:
|
||||
through the stats at <a rel="nofollow" href="http://orion.i2p/">http://orion.i2p/</a> and
|
||||
<a rel="nofollow" href="http://susi.i2p/susisworld.html">http://susi.i2p/susisworld.html</a>
|
||||
|
||||
* 4) eepsite roundup
|
||||
* 4) I2P site roundup
|
||||
|
||||
There have been some notable developments on various eepsites worth
|
||||
There have been some notable developments on various I2P sites worth
|
||||
mentioning:
|
||||
|
||||
= <a rel="nofollow" href="http://frosk.i2p/">http://frosk.i2p/</a> - I2PContent doc updates
|
||||
|
@@ -36,7 +36,7 @@ Nothing substantial to report here yet though.
|
||||
|
||||
Very brief summary, I know, but most of the work over the last week
|
||||
has been on paper. As mentioned [1] on the list, Connelly is
|
||||
running an intersection attack against some eepsites, so once
|
||||
running an intersection attack against some I2P sites, so once
|
||||
there's some data to report on, I'm sure he'll give us the scoop.
|
||||
Anyone else have anything to bring up - if so, swing on by the
|
||||
meeting.
|
||||
|
@@ -49,11 +49,11 @@ be a BACKWARDS INCOMPATIBLE RELEASE, to give you time to plan for
|
||||
updating, I'll fix a simple deadline of THIS FRIDAY as when 0.5
|
||||
will be released.
|
||||
|
||||
As bla mentioned on irc, eepsite hosts may want to take their site
|
||||
As bla mentioned on irc, I2P site hosts may want to take their site
|
||||
down on Thursday or Friday and keep them down until Saturday when
|
||||
many users will have upgraded. This will help reduce the effect of
|
||||
an intersection attack (e.g. if 90% of the network has migrated to
|
||||
0.5 and you're still on 0.4, if someone reaches your eepsite, they
|
||||
0.5 and you're still on 0.4, if someone reaches your I2P site, they
|
||||
know you're one of the 10% of routers left on the network).
|
||||
|
||||
I could start to get into whats been updated in 0.5, but I'd end up
|
||||
|
@@ -62,8 +62,8 @@ smeghead during the meeting?
|
||||
|
||||
Legion has also created a fork off the i2p-bt rev, merged in some
|
||||
other code, patched up some things, and has a windows binary
|
||||
available on his eepsite. The announcement [2] seems to suggest
|
||||
that source may be made available, though its not up on the eepsite
|
||||
available on his I2P site. The announcement [2] seems to suggest
|
||||
that source may be made available, though its not up on the I2P site
|
||||
at the moment. The i2p devs haven't audited (or even seen) the code
|
||||
to that client, so those who need anonymity may want to get and
|
||||
review a copy of the code first.
|
||||
|
@@ -15,7 +15,7 @@ Last week's 0.5.0.5 release has had its ups and downs - the major
|
||||
change to address some attacks in the netDb seems to work as
|
||||
expected, but has exposed some long overlooked bugs in the netDb's
|
||||
operation. This has caused some substantial reliability issues,
|
||||
especially for eepsites. The bugs have however been identified and
|
||||
especially for I2P sites. The bugs have however been identified and
|
||||
addressed in CVS, and those fixes among a few others will be pushed
|
||||
out as a 0.5.0.6 release within the next day.
|
||||
|
||||
|
@@ -13,7 +13,7 @@ Hi y'all, its that time of the week again,
|
||||
* 1) Net status
|
||||
|
||||
Over the nearly two weeks since 0.5.0.6 came out, things have been
|
||||
mostly positive, though service providers (eepsites, ircd, etc) have
|
||||
mostly positive, though service providers (I2P sites, ircd, etc) have
|
||||
been running into some bugs as of late. While clients are in good
|
||||
shape, over time a server may run into situation where failing
|
||||
tunnels can trigger some excessive throttling code, preventing
|
||||
|
@@ -53,7 +53,7 @@ there's a lot of work to do before its ready for joe sixpack,
|
||||
earlier this evening I was able to fire it up, browse sirup's shared
|
||||
files, grab some data, and use its *cough* "instant" chat interface.
|
||||
|
||||
There's lots more info up on sirup's eepsite [2], and help testing
|
||||
There's lots more info up on sirup's I2P site [2], and help testing
|
||||
by people already in the i2p community would be great (though
|
||||
please, until sirup blesses it as a public release, and i2p is at
|
||||
least 0.6 if not 1.0, lets keep it within the i2p community). I
|
||||
|
@@ -69,7 +69,7 @@ Can I hear a "w00t"?
|
||||
|
||||
As mentioned on the list and in the channel, we've got a new
|
||||
client app for secure and authenticated blogging / content
|
||||
distribution. With Syndie, the "is your eepsite up" question goes
|
||||
distribution. With Syndie, the "is your I2P site up" question goes
|
||||
away, as you can read the content even when the site is down, but
|
||||
Syndie avoids all the ugly issues inherent in content distribution
|
||||
networks by focusing on the frontend. Anyway, its very much a work
|
||||
|
@@ -18,7 +18,7 @@ some room for improvement, but it seems that the new netDb is
|
||||
performing as designed. We've even had the fallback tested out -
|
||||
when the floodfill peers are unreachable, routers fall back on the
|
||||
kademlia netDb, and the other day when that scenario occurred, irc
|
||||
and eepsite reliability was not substantially diminished.
|
||||
and I2P site reliability was not substantially diminished.
|
||||
|
||||
I did receive a question regarding how the new netDb works, and have
|
||||
posted up the answer [1] on my blog [2]. As always, if anyone has
|
||||
@@ -51,7 +51,7 @@ Susi has whipped up yet another web application for us - susidns [3].
|
||||
This serves as a simple interface for managing the addressbook app -
|
||||
its entries, subscriptions, etc. Its looking pretty good, so
|
||||
hopefully we'll be able to ship it as one of the default apps soon,
|
||||
but for now, its a snap to grab from her eepsite, save it to your
|
||||
but for now, its a snap to grab from her I2P site, save it to your
|
||||
webapps directory, restart your router, and you're good to go.
|
||||
|
||||
[3] <a rel="nofollow" href="http://susi.i2p/?page_id=13">http://susi.i2p/?page_id=13</a>
|
||||
|
@@ -33,7 +33,7 @@ peer review for I2P's anonymity [3]. The more I think about it the
|
||||
more I like it, though I think Raccoon23 is probably right in that
|
||||
we want to wait until 0.9/1.0-beta before running these types of
|
||||
contests. We could even do different contests for different
|
||||
applications on top of I2P - one for eepsites, one for irc users,
|
||||
applications on top of I2P - one for I2P sites, one for irc users,
|
||||
one for I2Phex users, one for anon-BT users, one for Syndie users,
|
||||
etc. This, meshed with the suggestion of trying with both passive
|
||||
'foxes' and fairly advanced 'foxes' should give us the opportunity
|
||||
|
@@ -71,7 +71,7 @@ Saying 2005 broke a lot of ground is a bit of an understatement -
|
||||
we've improved I2P numerous ways in the 25 releases last year,
|
||||
grew the network 5-fold, deployed several new client applications
|
||||
(Syndie, I2Phex, I2PSnark, I2PRufus), migrated to postman's and
|
||||
cervantes' new irc2p IRC network, and saw some useful eepsites
|
||||
cervantes' new irc2p IRC network, and saw some useful I2P sites
|
||||
bloom (such as zzz's stats.i2p, orion's orion.i2p, and tino's proxy
|
||||
and monitoring services, just to name a few). The community has
|
||||
also matured a bit more, in no small part thanks to the support
|
||||
|
@@ -95,7 +95,7 @@ long requested feature - support for persistent HTTP connections,
|
||||
allowing you to send multiple HTTP requests over a single stream,
|
||||
receiving multiple replies in return. I think someone first asked
|
||||
for this two years ago or so, and it could help with some types of
|
||||
eepsite or outproxying a bunch. I know the work isn't done yet, but
|
||||
I2P site or outproxying a bunch. I know the work isn't done yet, but
|
||||
its coming along. Hopefully zzz can give us a status update during
|
||||
the meeting.
|
||||
|
||||
|
@@ -10,7 +10,7 @@ large I2PSnark transfers completing, and with quite sustantial
|
||||
transfer rates achieved on individual routers - I've seen
|
||||
650KBytes/sec and 17,000 participating tunnels without any
|
||||
fireworks. Routers on the low end of the spectrum seem to be
|
||||
doing fine too, browsing eepsites and irc with 2 hop tunnels
|
||||
doing fine too, browsing I2P sites and irc with 2 hop tunnels
|
||||
using under 1KByte/sec average.
|
||||
|
||||
It isn't all roses for everyone though, but we're working through
|
||||
@@ -24,13 +24,13 @@ clearing up the initial bumps and bruises. To answer a frequent
|
||||
question, in the long run, both NTCP and SSU will be in operation -
|
||||
we are not reverting to TCP-only.
|
||||
|
||||
* Eepsite reachability
|
||||
* I2P Site reachability
|
||||
|
||||
Remember folks that eepsites are reachable only when the person
|
||||
Remember folks that I2P sites are reachable only when the person
|
||||
who is running it has it up - if they're down, there's nothing
|
||||
you can do to reach it ;) Unfortunately, for the past few days,
|
||||
orion.i2p hasn't been reachable, but the net is definitely still
|
||||
working - perhaps swing by inproxy.tino.i2p or eepsites.i2p for
|
||||
working - perhaps swing by inproxy.tino.i2p or I2P sites.i2p for
|
||||
your network survey needs.
|
||||
|
||||
Anyway, there's lots more going on, but it'd be a bit premature
|
||||
|
@@ -133,7 +133,7 @@ being worked on. First, from irc (and the not-yet-out-there FAQ):
|
||||
|
||||
<bar> a question i've been pondering is, who is later going to have
|
||||
balls big enough to host syndie production servers/archives?
|
||||
<bar> aren't those going to be as easy to track down as the eepsites
|
||||
<bar> aren't those going to be as easy to track down as the I2P sites
|
||||
are today?
|
||||
<jrandom> public syndie archives do not have the ability to
|
||||
*read* the content posted to forums, unless the forums publish
|
||||
|
@@ -10,7 +10,7 @@ independent of jrandom and *.i2p.net servers.
|
||||
Our new primary mirror is www.i2p2.de, accessible
|
||||
in I2P at www.i2p2.i2p.
|
||||
|
||||
Automatic updates will hosted on several eepsites,
|
||||
Automatic updates will hosted on several I2P sites,
|
||||
signed by Complication, for which purpose 0.6.1.31
|
||||
includes two new release verification keys.
|
||||
|
||||
|
@@ -86,7 +86,7 @@ Proxy
|
||||
Installer, Split Directories, Distro-Friendly Organization
|
||||
|
||||
<ul>
|
||||
<li>For new installs, code and data will be split into different directories. Data (router files, config files, i2psnark files, eepsite files, etc.) will be in ~/.i2p on linux and %APPDATA%\I2P on Windows. The code directory can be read-only to the user (although the user will not be able to update in that case). On linux, the shell scripts i2prouter, runplain.sh, and eepget can be moved to a directory such as /usr/bin. All assumptions that files are in the current working directory are removed. Don't launch the router anymore in the install scripts on linux.
|
||||
<li>For new installs, code and data will be split into different directories. Data (router files, config files, i2psnark files, I2P site files, etc.) will be in ~/.i2p on linux and %APPDATA%\I2P on Windows. The code directory can be read-only to the user (although the user will not be able to update in that case). On linux, the shell scripts i2prouter, runplain.sh, and eepget can be moved to a directory such as /usr/bin. All assumptions that files are in the current working directory are removed. Don't launch the router anymore in the install scripts on linux.
|
||||
<li>For existing installs, about the only visible change will be a few temporary files now in the Java temporary directory (e.g. /var/tmp on linux) instead of $I2P.
|
||||
</ul>
|
||||
|
||||
|
@@ -4,7 +4,7 @@ themes, translations, or standalone programs.
|
||||
Some plugins are already available for testing.
|
||||
We are hopeful this support will enable rapid development of innovative i2p applications.
|
||||
</p><p>
|
||||
The release fixes the blank-page bug when an eepsite is not reachable,
|
||||
The release fixes the blank-page bug when an I2P site is not reachable,
|
||||
and also improves handling of clock skews and IP changes.
|
||||
It adds support for a new, smaller tunnel build message,
|
||||
that will be tested in this release and enabled in the next release.
|
||||
|
@@ -19,7 +19,7 @@ Please volunteer on IRC #i2p-dev.
|
||||
</p>
|
||||
|
||||
<p>* Fix a severe memory leak in router I2CP session management that caused router crashes for people running the Robert bittorrent client
|
||||
<br />* Fix a bug from 0.8.2 that filtered cookies in the HTTP Server tunnel, causing authentication problems for some eepsites
|
||||
<br />* Fix a bug from 0.8.2 that filtered cookies in the HTTP Server tunnel, causing authentication problems for some I2P sites
|
||||
<br />* Several fixes for rare NPEs</p>
|
||||
|
||||
<p><strong>I2PSnark</strong></p>
|
||||
|
@@ -159,7 +159,7 @@ and <code>{{ https }}</code>. Even the domain names are different, it's the same
|
||||
{%- endtrans %}</p>
|
||||
<p>{% trans -%}
|
||||
Filtering is active on these outproxies (for example, mibbit and torrent
|
||||
tracker access is blocked). Eepsites
|
||||
tracker access is blocked). I2P Sites
|
||||
that are accessible via .i2p addresses are also not allowed via the outproxies.
|
||||
As a convenience, the outproxy blocks ad servers.
|
||||
{%- endtrans %}</p>
|
||||
|
@@ -238,7 +238,7 @@ as the default settings of 96 KB/s down / 40 KB/s up are fairly conservative.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans browserconfig=site_url('about/browser-config') -%}
|
||||
If you want to reach eepsites via your browser, have a look on the <a href="{{ browserconfig }}">browser proxy setup</a> page for an easy howto.
|
||||
If you want to reach I2P sites via your browser, have a look on the <a href="{{ browserconfig }}">browser proxy setup</a> page for an easy howto.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
{% endblock %}
|
||||
|
@@ -32,5 +32,5 @@ as the default settings of 96 KBps down / 40 KBps up are fairly slow.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans browserconfig=site_url('about/browser-config') -%}
|
||||
If you want to reach eepsites via your browser, have a look on the <a href="{{ browserconfig }}">browser proxy setup</a> page for an easy howto.
|
||||
If you want to reach I2P sites via your browser, have a look on the <a href="{{ browserconfig }}">browser proxy setup</a> page for an easy howto.
|
||||
{%- endtrans %}</p>
|
||||
|
@@ -32,7 +32,7 @@ that provides a streamlined way to use I2P applications and to browse I2P sites.
|
||||
Although it can provide access to the regular internet via an outproxy, it also
|
||||
integrates secure decentralized browsing, file sharing, and e-mail.{% endtrans %}
|
||||
</p>
|
||||
<img class="screenshot" src="{{ url_for('static', filename='images/browser/screenshots/2-eepsite.png') }}" />
|
||||
<img class="screenshot" src="{{ url_for('static', filename='images/browser/screenshots/2-I2P site.png') }}" />
|
||||
|
||||
<h2 id="landing">
|
||||
<span class="permalink">
|
||||
|
@@ -60,12 +60,12 @@ While Tor and I2P are similar in many ways, much of the terminology is different
|
||||
<tr><td>{{ _('Entry Guards') }}<td>{{ _('Fast Peers') }}
|
||||
<tr><td>{{ _('Entry Node') }}<td>{{ _('Inproxy') }}
|
||||
<tr><td>{{ _('Exit Node') }}<td>{{ _('Outproxy') }}
|
||||
<tr><td>{{ _('Hidden Service') }}<td>{{ _('Hidden Service') }}, {{ _('Eepsite or Destination') }}
|
||||
<tr><td>{{ _('Hidden Service') }}<td>{{ _('Hidden Service') }}, {{ _('I2P Site or Destination') }}
|
||||
<tr><td>{{ _('Hidden Service Descriptor') }}<td>{{ _('LeaseSet') }}
|
||||
<tr><td>{{ _('Introduction point') }}<td>{{ _('Inbound Gateway') }}
|
||||
<tr><td>{{ _('Node') }}<td>{{ _('Router') }}
|
||||
<tr><td>{{ _('Onion Proxy') }}<td>{{ _('I2PTunnel Client (more or less)') }}
|
||||
<tr><td>{{ _('Onion Service') }}<td>{{ _('Hidden Service') }}, {{ _('Eepsite or Destination') }}
|
||||
<tr><td>{{ _('Onion Service') }}<td>{{ _('Hidden Service') }}, {{ _('I2P Site or Destination') }}
|
||||
<tr><td>{{ _('Relay') }}<td>{{ _('Router') }}
|
||||
<tr><td>{{ _('Rendezvous Point') }}<td>{{ _('somewhat like Inbound Gateway + Outbound Endpoint') }}
|
||||
<tr><td>{{ _('Router Descriptor') }}<td>{{ _('RouterInfo') }}
|
||||
|
@@ -256,7 +256,7 @@ telnet <- ear <- i2p <- mouth <-----------'
|
||||
{% endhighlight %}
|
||||
|
||||
<p>{% trans -%}
|
||||
You can connect to EEPSITES too!
|
||||
You can connect to I2P SITES too!
|
||||
{%- endtrans %}</p>
|
||||
|
||||
{% highlight lang='text' %}
|
||||
@@ -289,7 +289,7 @@ $
|
||||
{% endhighlight %}
|
||||
|
||||
<p>{% trans -%}
|
||||
Pretty cool isn't it? Try some other well known EEPSITES if you like, nonexistent ones,
|
||||
Pretty cool isn't it? Try some other well known I2P SITES if you like, nonexistent ones,
|
||||
etc, to get a feel for what kind of output to expect in different situations.
|
||||
For the most part, it is suggested that you ignore any of the error messages.
|
||||
They would be meaningless to the application, and are only presented for human debugging.
|
||||
|
@@ -24,8 +24,8 @@ A web interface for I2PTunnel management is avaliable on
|
||||
<b>I2P Webserver</b> - A tunnel pointed to a Jetty webserver run
|
||||
on <a href="http://localhost:7658">localhost:7658</a> for convenient and quick hosting on I2P.
|
||||
<br>The document root is:{% endtrans %}
|
||||
<br><b>Unix</b> - $HOME/.i2p/eepsite/docroot
|
||||
<br><b>Windows</b> - %LOCALAPPDATA%\I2P\eepsite\docroot, which expands to: C:\Users\**username**\AppData\Local\I2P\eepsite\docroot
|
||||
<br><b>Unix</b> - $HOME/.i2p/I2P site/docroot
|
||||
<br><b>Windows</b> - %LOCALAPPDATA%\I2P\I2P site\docroot, which expands to: C:\Users\**username**\AppData\Local\I2P\I2P site\docroot
|
||||
</li>
|
||||
</ul>
|
||||
<h3 id="default-client-tunnels">{% trans %}Client tunnels{% endtrans %}</h3>
|
||||
@@ -177,7 +177,7 @@ Accept-encoding: x-i2p-gzip, replies with Content-encoding: x-i2p-gzip in such a
|
||||
<p>{% trans -%}
|
||||
Functions as both a I2PTunnel HTTP Server, and a I2PTunnel HTTP client with no outproxying
|
||||
capabilities. An example application would be a web application that does client-type
|
||||
requests, or loopback-testing an eepsite as a diagnostic tool.
|
||||
requests, or loopback-testing an I2P site as a diagnostic tool.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h3 id="server-mode-irc">IRC Server</h3>
|
||||
|
@@ -309,7 +309,7 @@ It could cause great harm both to our network and our reputation.
|
||||
|
||||
<h3>{% trans %}Join Us{% endtrans %}</h3>
|
||||
<p>{% trans -%}
|
||||
This may be obvious, but join the community. Run I2P 24/7. Start an eepsite about your project.
|
||||
This may be obvious, but join the community. Run I2P 24/7. Start an I2P site about your project.
|
||||
Hang out in IRC #i2p-dev. Post on the forums. Spread the word.
|
||||
We can help get you users, testers, translators, or even coders.
|
||||
{%- endtrans %}</p>
|
||||
|
@@ -147,7 +147,7 @@ provider, and as he likes to say, "trust is not a boolean".
|
||||
The configuration step attempts to force users to think about issues of trust in an anonymous network.
|
||||
{%- endtrans %}</p>
|
||||
<p>{% trans -%}
|
||||
As another example, the "Eepsite Unknown" error page in the HTTP Proxy
|
||||
As another example, the "I2P Site Unknown" error page in the HTTP Proxy
|
||||
lists some jump services, but doesn't "recommend" any one in particular,
|
||||
and it's up to the user to pick one (or not).
|
||||
jrandom would say we trust the listed providers enough to list them but not enough to
|
||||
@@ -196,7 +196,7 @@ the issues of conflicts and hijacking, however.
|
||||
<p>{% trans -%}
|
||||
<b>Awkward, not real-time:</b>
|
||||
It's a patchwork of hosts.txt providers, key-add web form providers, jump service providers,
|
||||
eepsite status reporters.
|
||||
I2P site status reporters.
|
||||
Jump servers and subscriptions are a pain, it should just work like DNS.
|
||||
{%- endtrans %}</p>
|
||||
<p>{% trans -%}
|
||||
|
@@ -161,7 +161,7 @@ the netDb.
|
||||
I2P's netDb is very different from traditional load bearing DHTs - it only
|
||||
carries network metadata, not any actual payload, which is why even a netDb
|
||||
using a floodfill algorithm will be able to sustain an arbitrary amount of
|
||||
eepsite/IRC/bt/mail/syndie/etc data. We can even do some optimizations as I2P
|
||||
I2P site/IRC/bt/mail/syndie/etc data. We can even do some optimizations as I2P
|
||||
grows to distribute that load a bit further (perhaps passing bloom filters
|
||||
between the netDb participants to see what they need to share), but it seems we
|
||||
can get by with a much simpler solution for now.
|
||||
@@ -299,7 +299,7 @@ The code now avoids peers that are shitlisted, failing, or not heard from in
|
||||
half an hour, if possible.
|
||||
</ol>
|
||||
<p>
|
||||
One benefit is faster first contact to an eepsite (i.e. when you had to fetch
|
||||
One benefit is faster first contact to an I2P site (i.e. when you had to fetch
|
||||
the leaseset first). The lookup timeout is 10s, so if you don't start out by
|
||||
asking a peer that is down, you can save 10s.
|
||||
|
||||
|
@@ -25,7 +25,7 @@ even taken over to attempt more malicious attacks.
|
||||
<p>{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
|
||||
The network itself is message oriented - it is essentially a secure and anonymous IP layer, where
|
||||
messages are addressed to cryptographic keys (Destinations) and can be significantly larger than IP
|
||||
packets. Some example uses of the network include "eepsites" (webservers hosting normal web
|
||||
packets. Some example uses of the network include "I2P sites" (webservers hosting normal web
|
||||
applications within I2P), a BitTorrent client ("I2PSnark"), or a distributed data store. With the
|
||||
help of the <a href="{{ i2ptunnel }}">I2PTunnel</a> application, we are able to stream traditional
|
||||
TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even streaming audio. Most people
|
||||
|
@@ -836,7 +836,7 @@ by creating a small number (8-15) of floodfill routers clustered closely in the
|
||||
and distribute the RouterInfos for these routers widely.
|
||||
Then, all lookups and stores for a key in that keyspace would be directed
|
||||
to one of the attacker's routers.
|
||||
If successful, this could be an effective DOS attack on a particular eepsite, for example.
|
||||
If successful, this could be an effective DOS attack on a particular I2P site, for example.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
|
@@ -100,7 +100,7 @@ usually a secret. What is hidden is information on what the user is doing,
|
||||
if anything at all, as well as what router a particular destination is connected
|
||||
to. End users will typically have several local destinations on their router
|
||||
- for instance, one proxying in to IRC servers, another supporting the user's
|
||||
anonymous webserver ("eepsite"), another for an I2Phex instance, another for
|
||||
anonymous webserver ("I2P site"), another for an I2Phex instance, another for
|
||||
torrents, etc.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
@@ -904,7 +904,7 @@ system. It lets you create information, share it with others, and read posts
|
||||
from those you're interested in, all while taking into consideration your
|
||||
needs for security and anonymity. Rather than building its own content distribution
|
||||
network, Syndie is designed to run on top of existing networks, syndicating
|
||||
content through eepsites, Tor hidden services, Freenet freesites, normal websites,
|
||||
content through I2P sites, Tor hidden services, Freenet freesites, normal websites,
|
||||
usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie
|
||||
is done so as to offer pseudonymous authentication to anyone reading or archiving
|
||||
it.
|
||||
@@ -945,7 +945,7 @@ be sufficient for some users.
|
||||
|
||||
<p>{% trans -%}
|
||||
I2PTunnel enables most of the applications in use. An "httpserver" pointing
|
||||
at a webserver lets anyone run their own anonymous website (or "eepsite")
|
||||
at a webserver lets anyone run their own anonymous website (or "I2P site")
|
||||
- a webserver is bundled with I2P for this purpose, but any webserver can
|
||||
be used. Anyone may run a "client" pointing at one of the anonymously hosted
|
||||
IRC servers, each of which are running a "server" pointing at their local
|
||||
@@ -963,7 +963,7 @@ proxies to access the "server" instances pointing at an NNTP server.
|
||||
<p>{% trans -%}
|
||||
i2p-bt is a port of the mainline python BitTorrent client to run both the
|
||||
tracker and peer communication over I2P. Tracker requests are forwarded through
|
||||
the eepproxy to eepsites specified in the torrent file while tracker responses
|
||||
the eepproxy to I2P sites specified in the torrent file while tracker responses
|
||||
refer to peers by their destination explicitly, allowing i2p-bt to open up
|
||||
a <a href="#app.streaming">streaming lib</a> connection to query them for
|
||||
blocks.
|
||||
@@ -1041,7 +1041,7 @@ SMTP and POP3 servers - both the outproxies and inproxies communicate with
|
||||
the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those
|
||||
non-anonymous locations does not give access to the mail accounts or activity
|
||||
patterns of the user. At the moment the developers work on a decentralized
|
||||
mailsystem, called "v2mail". More information can be found on the eepsite
|
||||
mailsystem, called "v2mail". More information can be found on the I2P site
|
||||
<a href="http://{{ postman }}/">{{ postman }}</a>.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
@@ -231,7 +231,7 @@ However, the attack is still possible, for example by an observer at
|
||||
a large ISP or an Internet exchange point.
|
||||
Those who want to defend against it
|
||||
would want to take appropriate countermeasures, such as
|
||||
setting low bandwidth limits, and using unpublished or encrypted leasesets for eepsites.
|
||||
setting low bandwidth limits, and using unpublished or encrypted leasesets for I2P sites.
|
||||
Other countermeasures, such as nontrivial delays and restricted routes, are
|
||||
not currently implemented.
|
||||
{%- endtrans %}</p>
|
||||
@@ -323,7 +323,7 @@ Limits on the number of tunnels routed through a single peer
|
||||
Prevention of peers from the same /16 IP range from being members of a single tunnel
|
||||
{%- endtrans %}</li>
|
||||
<li>{% trans -%}
|
||||
For eepsites or other hosted services, we support
|
||||
For I2P sites or other hosted services, we support
|
||||
simultaneous hosting on multiple routers, or
|
||||
<a href="#intersection">multihoming</a>
|
||||
{%- endtrans %}</li>
|
||||
|
@@ -165,7 +165,7 @@ For more information see the <a href="{{ namingdiscussion }}#alternatives">alter
|
||||
<p>{% trans -%}
|
||||
The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'.
|
||||
Otherwise, it forwards the request to a configured HTTP outproxy.
|
||||
Thus, in practice, all HTTP (eepsite) hostnames must end in the pseudo-Top Level Domain '.i2p'.
|
||||
Thus, in practice, all HTTP (I2P site) hostnames must end in the pseudo-Top Level Domain '.i2p'.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans i2ptld='https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/',
|
||||
@@ -337,7 +337,7 @@ See <a href="/spec/subscription">the specification</a> for details.
|
||||
<h3>{% trans %}Outgoing Subscriptions{% endtrans %}</h3>
|
||||
<p>{% trans -%}
|
||||
Addressbook will publish the merged hosts.txt to a location
|
||||
(traditionally hosts.txt in the local eepsite's home directory) to be accessed by others
|
||||
(traditionally hosts.txt in the local I2P site's home directory) to be accessed by others
|
||||
for their subscriptions.
|
||||
This step is optional and is disabled by default.
|
||||
{%- endtrans %}</p>
|
||||
|
@@ -44,7 +44,7 @@ in the 767x range.
|
||||
<tr><td>7655</td><td>SAM Bridge (UDP)</td></tr>
|
||||
<tr><td>7656</td><td>SAM Bridge (TCP)</td></tr>
|
||||
<tr><td>7657</td><td>Router Console</td></tr>
|
||||
<tr><td>7658</td><td>Eepsite</td></tr>
|
||||
<tr><td>7658</td><td>I2P Site</td></tr>
|
||||
<tr><td>7659</td><td>SMTP Proxy</td></tr>
|
||||
<tr><td>7660</td><td>POP Proxy</td></tr>
|
||||
<tr><td>7661</td><td>Pebble Plugin</td></tr>
|
||||
@@ -54,7 +54,7 @@ in the 767x range.
|
||||
<tr><td>7663</td><td>?? Plugin ??</td></tr>
|
||||
<tr><td>7664</td><td>JAMWiki Plugin</td></tr>
|
||||
<tr><td>7667</td><td>Router Console SSL</td></tr>
|
||||
<tr><td>7668</td><td>Eepsite SSL</td></tr>
|
||||
<tr><td>7668</td><td>I2P Site SSL</td></tr>
|
||||
<tr><td>7669</td><td>Garlic Farm</td></tr>
|
||||
<tr><td>7670</td><td>Git SSH</td></tr>
|
||||
<tr><td></td><td><i>{% trans %}recommended spot for new plugins/applications{% endtrans %}</i></td></tr>
|
||||
|
@@ -82,7 +82,7 @@ The paper's main point is that
|
||||
deanonymizations on unidirectional tunnels take a longer time, which is an
|
||||
advantage, but that an attacker can be more certain in the unidirectional case.
|
||||
Therefore, the paper claims it isn't an advantage at all, but a disadvantage, at least
|
||||
with long-living eepsites.
|
||||
with long-living I2P sites.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
@@ -97,7 +97,7 @@ This conclusion is based on an arbitrary certainty vs. time weighting
|
||||
(tradeoff) that may not be applicable in all cases. For
|
||||
example, somebody could make a list of possible IPs then issue subpoenas to
|
||||
each. Or the attacker could DDoS each in turn and via a simple
|
||||
intersection attack see if the eepsite goes down or is slowed down. So close
|
||||
intersection attack see if the I2P site goes down or is slowed down. So close
|
||||
may be good enough, or time may be more important.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
@@ -7,20 +7,20 @@
|
||||
</li>
|
||||
<li><a href="#systems">{% trans %}What systems will I2P run on?{% endtrans %}</a></li>
|
||||
<li><a href="#java">{% trans %}Is installing Java required to use I2P?{% endtrans %}</a></li>
|
||||
<li><a href="#eepsite">{% trans %}Whats an "eepsite" and how do I configure my browser so I can use them?{% endtrans %}</a></li>
|
||||
<li><a href="#I2P site">{% trans %}Whats an "I2P site" and how do I configure my browser so I can use them?{% endtrans %}</a></li>
|
||||
<li><a href="#active">{% trans %}What do the Active x/y numbers mean in the router console?{% endtrans %}</a></li>
|
||||
<li><a href="#peers">{% trans %}My router has very few active peers, is this OK?{% endtrans %}</a></li>
|
||||
<li><a href="#badcontent">{% trans %}I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?{% endtrans %}</a></li>
|
||||
<li><a href="#blocking">{% trans %}Is it possible to block I2P?{% endtrans %}</a></li>
|
||||
<li><a href="#protocolfamily">{% trans %}In <code>wrapper.log</code> I see an error stating <code>Protocol family unavailable</code> when I2P is loading{% endtrans %}</a></li>
|
||||
<li><a href="#down">{% trans %}Most of the eepsites within I2P are down?{% endtrans %}</a></li>
|
||||
<li><a href="#down">{% trans %}Most of the I2P sites within I2P are down?{% endtrans %}</a></li>
|
||||
<li><a href="#port32000">{% trans %}Why is I2P listening for connections on port 32000?{% endtrans %}</a></li>
|
||||
<li style="list-style: none; display: inline">
|
||||
<h4>{{ _('Configuration') }}</h4>
|
||||
</li>
|
||||
<li><a href="#browserproxy">{% trans %}How do I configure my browser?{% endtrans %}</a></li>
|
||||
<li><a href="#irc">{% trans %}How do I connect to IRC within I2P?{% endtrans %}</a></li>
|
||||
<li><a href="#myeepsite">{% trans %}How do I set up my own eepsite?{% endtrans %}</a></li>
|
||||
<li><a href="#myI2P site">{% trans %}How do I set up my own I2P site?{% endtrans %}</a></li>
|
||||
<li><a href="#hosting">{% trans %}If I host a website at I2P at home, containing only HTML and CSS, is it dangerous?{% endtrans %}</a></li>
|
||||
<li><a href="#addresses">{% trans %}How Does I2P find ".i2p" websites?{% endtrans %}</a></li>
|
||||
<li><a href="#addressbook">{% trans %}How do I add to the AddressBook?{% endtrans %}</a></li>
|
||||
@@ -97,11 +97,11 @@ While the main I2P client implementation requires Java, there are several
|
||||
<a href="{{ alt }}">alternative clients</a> which don't require Java.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h3 id="eepsite"><span class="permalink"><a href="#eepsite">
|
||||
{% trans %}What is an I2P Site or "eepsite?"{% endtrans %}</a></span>
|
||||
<h3 id="I2P site"><span class="permalink"><a href="#I2P site">
|
||||
{% trans %}What is an "I2P Site?"{% endtrans %}</a></span>
|
||||
</h3>
|
||||
<p>{% trans -%}
|
||||
An eepsite is a website that is hosted anonymously, a hidden service which is accessible through your web browser.
|
||||
Formerly called an eepSite, an I2P site is a website that is hosted anonymously, a hidden service which is accessible through your web browser.
|
||||
It can be accessed by setting your web browser's HTTP proxy to use the I2P web proxy (typically it listens on localhost port 4444), and browsing to the site.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
@@ -186,13 +186,13 @@ click <em>Shutdown</em>, wait 11 minutes, then start I2P.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h3 id="down"><span class="permalink"><a href="#down">
|
||||
{% trans %}Most of the eepsites within I2P are down?{% endtrans %}</a></span>
|
||||
{% trans %}Most of the I2P sites within I2P are down?{% endtrans %}</a></span>
|
||||
</h3>
|
||||
<p>{% trans eepstatus='http://'+i2pconv('identiguy.i2p') -%}
|
||||
If you consider every eepsite that has ever been created, yes, most of them are down.
|
||||
People and eepsites come and go.
|
||||
A good way to get started in I2P is check out a list of eepsites that are currently up.
|
||||
<a href="{{ eepstatus }}">{{ eepstatus }}</a> tracks active eepsites.
|
||||
If you consider every I2P site that has ever been created, yes, most of them are down.
|
||||
People and I2P sites come and go.
|
||||
A good way to get started in I2P is check out a list of I2P sites that are currently up.
|
||||
<a href="{{ eepstatus }}">{{ eepstatus }}</a> tracks active I2P sites.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h3 id="port32000"><span class="permalink"><a href="#port32000">
|
||||
@@ -232,8 +232,8 @@ Weechat users can use the following command to add a new network:
|
||||
</pre>
|
||||
</code>
|
||||
|
||||
<h3 id="myeepsite"><span class="permalink"><a href="#myeepsite">
|
||||
{% trans %}How do I set up my own eepsite?{% endtrans %}</a></span>
|
||||
<h3 id="myI2P site"><span class="permalink"><a href="#myI2P site">
|
||||
{% trans %}How do I set up my own I2P site?{% endtrans %}</a></span>
|
||||
</h3>
|
||||
<p>{% trans -%}
|
||||
Click on the <a href="http://localhost:7658/">Website</a> link at the top of your router console for instructions.
|
||||
@@ -440,7 +440,7 @@ These are described in detail below.
|
||||
7658
|
||||
</td>
|
||||
<td>
|
||||
Your <a href="http://127.0.0.1:7658">eepsite</a>
|
||||
Your <a href="http://127.0.0.1:7658">I2P site</a>
|
||||
</td>
|
||||
<td>
|
||||
{% trans -%}May be disabled in the <code>clients.config</code> file.
|
||||
|
@@ -207,7 +207,7 @@ to and from I2P. At this point in time it lacks UDP support, but UDP support
|
||||
is planned in the near future. BOB also contains several tools, such as
|
||||
destination key generation, and verification that an address conforms to
|
||||
I2P specifications. Up to date info and applications that use BOB can be
|
||||
found at this <a href="http://{{ boburl }}/">eepsite</a>.
|
||||
found at this <a href="http://{{ boburl }}/">I2P site</a>.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
|
@@ -15,7 +15,7 @@ signature for his key.
|
||||
</ol>
|
||||
<h3 id="monotone-keys-for-zzz">{{ _('Monotone keys for zzz') }}</h3>
|
||||
<p>{% trans -%}
|
||||
<u>Tip:</u> To find zzz's GPG key, on his eepsite locate the key `0xA76E0BED`, with
|
||||
<u>Tip:</u> To find zzz's GPG key, on his I2P site locate the key `0xA76E0BED`, with
|
||||
the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 B310 4155
|
||||
76BA A76E 0BED`.
|
||||
{%- endtrans %}</p>
|
||||
@@ -79,7 +79,7 @@ the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 B310 4155
|
||||
<h3 id="monotone-keys-for-complication">{{ _('Monotone keys for Complication') }}</h3>
|
||||
|
||||
<p>{% trans -%}
|
||||
<b>Tip:</b> To find Complication's GPG key, on his eepsite locate the key
|
||||
<b>Tip:</b> To find Complication's GPG key, on his I2P site locate the key
|
||||
`0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint `73CF
|
||||
2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`.
|
||||
{%- endtrans %}</p>
|
||||
|
@@ -120,7 +120,7 @@ There are about 15 files in the i2p.i2p branch that needs translation:
|
||||
<li>
|
||||
<code>apps/routerconsole/jsp/help_xx.jsp</code></li>
|
||||
<li>
|
||||
<code>installer/resources/eepsite.help/help/index_xx.html</code></li>
|
||||
<code>installer/resources/I2P site.help/help/index_xx.html</code></li>
|
||||
<li>
|
||||
<code>apps/i2ptunnel/locale/messages_xx.po</code></li>
|
||||
<li>
|
||||
|
@@ -191,7 +191,7 @@ Optional:
|
||||
|
||||
<p>
|
||||
This How-to is tested with Ubuntu/Debian as well as FreeBSD.
|
||||
The web server has to be public reachable from all over the world, an eepsite inside I2P can be setup in addition.
|
||||
The web server has to be public reachable from all over the world, an I2P site inside I2P can be setup in addition.
|
||||
Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server.
|
||||
The web server doesn't need to listen at default SSL/TLS port 443 - any other port can be used for obfuscation.
|
||||
</p>
|
||||
|
@@ -57,7 +57,7 @@ your guide is helpful, we'd love to mirror it on our blog.
|
||||
</li><li><b>{{ _('Content') }}</b> —
|
||||
{% trans -%}
|
||||
One of I2P's greatest strengths as a peer-to-peer network is that anyone can
|
||||
run their own website, it's actually a built-in feature. Create an eepSite,
|
||||
run their own website, it's actually a built-in feature. Create an I2P Site,
|
||||
talk about something you're passionate about, or just interested in. It's easy,
|
||||
and it's getting easier every single day. Announce it on <a href="https://reddit.com/r/i2p">r/i2p</a>
|
||||
and <a href="http://i2pforum.i2p">i2pforum.i2p</a>/<a href="https://i2pforum.net">i2pforum.net</a>
|
||||
@@ -68,7 +68,7 @@ you will have visitors in no time.
|
||||
<ul>
|
||||
<li><b>{{ _('Services') }}</b> —
|
||||
{% trans -%}
|
||||
Running many kinds of services on eepSites is very easy. You could self-host
|
||||
Running many kinds of services on I2P Sites is very easy. You could self-host
|
||||
almost anything, from an SSH server for yourself to an ActivityPub forum for
|
||||
everyone and anything in between. Almost anything you can think of can be made
|
||||
to work with I2P, and your service is valuable to the network.
|
||||
|
@@ -204,7 +204,7 @@ Donation page redesign and backend (deployment)
|
||||
</li><li>
|
||||
New console prototype
|
||||
</li><li>
|
||||
Enable setting up the Jetty eepSite with a custom directory from the I2PTunnel Wizard (Or otherwise enable serving a static directory of files using only I2PTunnel)
|
||||
Enable setting up the Jetty I2P Site with a custom directory from the I2PTunnel Wizard (Or otherwise enable serving a static directory of files using only I2PTunnel)
|
||||
</li><li>
|
||||
Outproxy requirements
|
||||
</li><li>
|
||||
@@ -448,7 +448,7 @@ IPv6 address selection improvements
|
||||
</li><li>
|
||||
Better tunnel peer selection for hidden and IPv6-only modes
|
||||
</li><li>
|
||||
Prep for HTTPS console and eepsite by default
|
||||
Prep for HTTPS console and I2P site by default
|
||||
</li><li>
|
||||
Prep for splitting up Debian package
|
||||
</li><li>
|
||||
@@ -467,7 +467,7 @@ Tomcat 8.5.30
|
||||
</li><li>
|
||||
Susimail folders, background sending
|
||||
</li><li>
|
||||
Improved support for SSL console and eepsite
|
||||
Improved support for SSL console and I2P site
|
||||
</li><li>
|
||||
Bug fixes, translation updates, geoip updates
|
||||
</li><li>
|
||||
|
@@ -6,7 +6,7 @@
|
||||
<p>{% trans -%}
|
||||
After upgrading to the new architecture, you'll have to do a
|
||||
little work to get your old I2PTunnel-driven servers running.
|
||||
Lets walk through a simple example. For an eepsite with the
|
||||
Lets walk through a simple example. For an I2P site with the
|
||||
old clientApp configuration, you had:
|
||||
{%- endtrans %}</p>
|
||||
<pre>
|
||||
@@ -18,8 +18,8 @@ old clientApp configuration, you had:
|
||||
<li>{% trans url='http://localhost:7657/i2ptunnel/' %}Jump to <a href="{{ url }}">{{ url }}</a>{% endtrans %}</li>
|
||||
<li>{% trans %}Click on Add new: [Server tunnel] "GO"{% endtrans %}</li>
|
||||
<li><ul>
|
||||
<li>{% trans %}For the name: <code>"eepsite"</code>{% endtrans %}</li>
|
||||
<li>{% trans %}For the description: <code>"My eepsite, isn't it pretty?"</code>{% endtrans %}</li>
|
||||
<li>{% trans %}For the name: <code>"I2P site"</code>{% endtrans %}</li>
|
||||
<li>{% trans %}For the description: <code>"My I2P site, isn't it pretty?"</code>{% endtrans %}</li>
|
||||
<li{% trans %}>For the target host:{% endtrans %} <code>localhost</code></li>
|
||||
<li>{% trans %}For the target port:{% endtrans %} <code>80</code></li>
|
||||
<li>{% trans -%}
|
||||
|
@@ -2,7 +2,7 @@
|
||||
{% block title %}{% trans %}I2PTunnel services{% endtrans %}{% endblock %}
|
||||
{% block content %}
|
||||
<p>{% trans -%}
|
||||
Below is quick copy of aum's eepsite deployment guide.
|
||||
Below is quick copy of aum's I2P site deployment guide.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<strong>{% trans %}1. - Deploy a local server{%- endtrans %}</strong>
|
||||
|
@@ -11,17 +11,17 @@ with version 0.9.5. Other operating systems are not affected.
|
||||
|
||||
<h2>Background</h2>
|
||||
<p>A change was introduced during the 0.9.5 cycle to allow I2P's configuration files to be edited with the standard
|
||||
Windows text editor, <code>Notepad</code>. This change had the unfortunate side-effect of causing our eepsite migration code to
|
||||
fail to run on Windows systems, leading to eepsites being served from the installation directory. Consequently:
|
||||
Windows text editor, <code>Notepad</code>. This change had the unfortunate side-effect of causing our I2P site migration code to
|
||||
fail to run on Windows systems, leading to I2P sites being served from the installation directory. Consequently:
|
||||
</p>
|
||||
<ul>
|
||||
<li>depending upon how I2P is started, the eepsite may not be accessible; and</li>
|
||||
<li>confusion ensues—all documentation states that eepsites are served from the profile path; and</li>
|
||||
<li>depending upon how I2P is started, the I2P site may not be accessible; and</li>
|
||||
<li>confusion ensues—all documentation states that I2P sites are served from the profile path; and</li>
|
||||
<li>the update to Jetty 7, included in the 0.9.6 release, will fail.</li>
|
||||
</ul>
|
||||
<p>While no action is required for users that are not hosting an eepsite (or are not using the included Jetty to host an eepsite), it is
|
||||
recommended to follow this procedure to avoid issues in case you decide to run a Jetty-hosted eepsite in the future. If you are running an
|
||||
eepsite it is important to follow this procedure prior to upgrading to 0.9.6.
|
||||
<p>While no action is required for users that are not hosting an I2P site (or are not using the included Jetty to host an I2P site), it is
|
||||
recommended to follow this procedure to avoid issues in case you decide to run a Jetty-hosted I2P site in the future. If you are running an
|
||||
I2P site it is important to follow this procedure prior to upgrading to 0.9.6.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -46,20 +46,20 @@ eepsite it is important to follow this procedure prior to upgrading to 0.9.6.
|
||||
You should see something like the following:
|
||||
<a href="{{ url_for('static', filename='images/ticket919/paths.png') }}">
|
||||
<img alt="" style="padding:10px;margin-left:auto;margin-right:auto;display:block" src="{{ url_for('static', filename='images/ticket919/paths.png') }}" /></a>
|
||||
If the path at number 1 in the image above is set to <code>eepsite/jetty.xml</code>, the path needs to be updated.
|
||||
If the path at number 1 in the image above is set to <code>I2P site/jetty.xml</code>, the path needs to be updated.
|
||||
</li>
|
||||
<li>Click the <code>Edit</code> button next to <em>I2P webserver (eepsite)</em>. The page will reload to allow the path to be edited as shown below:
|
||||
<li>Click the <code>Edit</code> button next to <em>I2P webserver (I2P site)</em>. The page will reload to allow the path to be edited as shown below:
|
||||
<a href="{{ url_for('static', filename='images/ticket919/edit.png') }}">
|
||||
<img alt="" style="padding:10px;margin-left:auto;margin-right:auto;display:block" src="{{ url_for('static', filename='images/ticket919/edit.png') }}" /></a>
|
||||
Insert the full path to your I2P configuration directory <em>before</em> the text "eepsite/jetty.xml" as shown above,
|
||||
Insert the full path to your I2P configuration directory <em>before</em> the text "I2P site/jetty.xml" as shown above,
|
||||
then click Click the <code>Save Client Configuration</code> button.
|
||||
</li>
|
||||
<li> If you're hosting an eepsite, move its contents to its proper home at <code>%APPDATA%\I2P\eepsite\docroot</code>.
|
||||
<li> If you're hosting an I2P site, move its contents to its proper home at <code>%APPDATA%\I2P\I2P site\docroot</code>.
|
||||
</li>
|
||||
<li>At this point you should restart your I2P router.</li>
|
||||
</ol>
|
||||
|
||||
<p>After following the steps outlined above, your eepsite will be served from <code>%APPDATA%\I2P\eepsite\docroot</code>
|
||||
<p>After following the steps outlined above, your I2P site will be served from <code>%APPDATA%\I2P\I2P site\docroot</code>
|
||||
and should be accessible at <a href="http://127.0.0.1:7658">http://127.0.0.1:7658</a>.
|
||||
</p>
|
||||
{% endblock %}
|
||||
|
@@ -12,7 +12,7 @@ This process is subject to change. Please refer to this page for the current VRP
|
||||
<p>{% trans %}Researchers: while you research/hack, we ask that you refrain from the following: - Performing active exploits or Denial of Service attacks on the
|
||||
i2p network - Performing social engineering on i2p development team members - Performing any physical or electronic attempts against i2p property and/or data
|
||||
centers{%- endtrans %}</p>
|
||||
<p>{% trans %}As i2p is an open-source community, many volunteers and development team members run their own EepSites as well as public (“non-private internet”) domains. These
|
||||
<p>{% trans %}As i2p is an open-source community, many volunteers and development team members run their own I2P Sites as well as public (“non-private internet”) domains. These
|
||||
sites/servers are NOT in the scope of the vulnerability assessment / response process, only the underlying code of i2p is.{%- endtrans %}</p>
|
||||
|
||||
<h2 id="i.-point-of-contact-for-security-issues">I. {{ _('Point of Contact for Security Issues') }}</h2>
|
||||
|
Reference in New Issue
Block a user