Finally, today the list was cleared. So I guess it has more something to do with the fact that I'm the only seeder or not.

I've uploaded some more torrents and some are now 'Visible' and some not, and non of them had been post as anonymous. So it's still a bit obscure...

I understand but I have at least one other torrent where the owner name is note hidden and it does not appear on that list. So my question...

This is only related to others peers knowing about the uploader of the torrent files, not the uploader's IP address. When you upload a Torrent on the Postman Tracker, you can decide whether to upload the torrent as an anonymous uploader or with your Username. In this case your username is visible, and that's alright.

Honestly I'm unsure, Since most i2p-portable projects I know are way out of date now, including Prestium. I believe that you can run I2Pd-Browser on an external flash drive directly, but idk about running a daemon on portable mode.

If you already figured out a proper solution, a clarified reply would really be appreciated. I'm also wondering how to run I2P on an external storage; whether under a windows or a Linux system.

If you read the column heading again, you'll notice that the visibility relates to ownership of the torrents, not your IP address. In other words, your login name will appear next to the torrents you have uploaded. There is an option to hide your username if that's desirable, but otherwise, nothing is visible to other users.

You're Welcome, I haven't heard of this project before, so I can't say if you should use it or not. I usually just use Invidious/Piped instances, and sometimes Freetube as well, however It's still a good thing that there are alternatives. For Tube, If you already compiled it and it works well with you, let me know if it's worth the build.

Curiously, I was wondering if there were any clients written in Rust, and I found this. It uses Tauri and I like the fact this it is way less bloated and more efficient than Electron clients (e.g. Freetube). Though, the RustyTube project is still in its early stages, but still sounds cool to give it a try nonetheless.

Thanks Chronic. Think I can use https://git.mills.io/prologic/tube from here since it seems a bit more useful and stuff? I'm sure it could be worth a try hosting a separate video host or something.

1. Nope, the site doesn't work with either because it is already down.
2. I2pd rocks, and so as the other clients, as long it works well with whomever uses them.

Well, you just answered your own question. Tube.i2p used to be an anonymous YT frontend, but in reality it was so slow and unreliable, so don't even bother.

If you need to, you can simply use an outproxy and connect directly to any YT frontend of your choice that is near you; would be more reliable than an eepsite/hidden-service. It's also a good idea to create a separate profile for your outproxy use-cases, especially for installing extensions like Libredirect, Sponsorblock, etc..

i2pd offers a http proxy server, it works well.

i2pd is great, if you are ok with flat config files and no limits.

1. Site don't working with socks proxy. Must be http.
2. I2pd sucks.

it probably could, to me that along with traffic analysis are things that fall more into state sponsored level attack. guess avoiding those chipsets is the way or disabling it, but only 3 people are going to do that. like i'd think that at least with intel it's basically a backdoor, probably would take a fair amount of effort for someone outside of them to exploit it. but i guess that doesn't stop intel from gathering intel, lol

there's a surprising amount of low-lying fruit that can be way easier to do for non state actors. Best to assume your ip address is known to be running i2p as public knowledge, and like just poking around the netdb will give info that can sometimes lead to deanon if not careful

I wonder how the intel management engine and AMD PSP could be used to track I2P users. They make up the majority of the nodes on this network. We really don't have a way to fight that unless we all jump to RISC-V right? Also, that article is interesting but incredibly outdated. It's from 2010. Id imagine the security posture of i2p has improved dramatically since then.

you should be able to set the port like z3d said and it'll only use that, dangerous to share obviously because port scanning could be done to identify from suspected ips

i think in theory this is probably true to an extent, we're getting into the realm of traffic analysis. There's some info on this on http://i2p-projekt.i2p/en/docs/how/threat-model

As not_bob mentioned, it's useful.

I2P+ comes with feature rich console interface, one that also happens to be a great place for beginners to start out - doesn't mean users would need to keep the outproxy.

Some otherwise might not have opportunity to try outproxy (some lazy, some unsure how).

And having access to browse clearnet also means a user is more likely to keep an i2p browser (in turn, i2prouter) set up - this means more traffic for all of us. And that's good for all.

In this way, I'd say it's a win win, to have built in (by default, not required to keep).

incorrect. The port the relay uses to the outside world is random and not to be disclosed, and certainly never a fixed port posted on a ramble post. Also, this fails to address my question. products like the firewalla purple can phone home and keep track of all the connections made on the port I granted a firewall exception to. My question was whats stopping the companies behind these products (or even just he ISPs themselves) from linking all the connections people are making on I2P? They wouldn't know the content of the data being sent but they would be able to piece together the paths it took potentially leading to deanon.

i gave tuckit a "force_outbound_quantity = x" to get around it, that would be even better :)

I can fix the display so if it's over the limit it still shows correctly.

There's no way to create an exception for i2p as the destinations vary.

Allow all inbound and outbound traffic on your configured TCP and UDP port indicated on http://127.0.0.1:7657/confignet#udpconfig in I2P+. You should expect that traffic to only be handled by your Java runtime. No other ports on I2P need to exposed publicly (in your firewall).

Just if anyone finds this, the outproxy is disabled by default in i2pd.

i'm not completely sure but i'd hazard a guess that it could have something to do with i2p+ being more selective in it's peer profiling compared to i2pd and that java routers use different bids for NTCP2 and SSU2

emissary is super exciting, just kinda showed up out of nowhere

It's very useful to have a working outproxy. You will find many sites that are banned when you use Tor, but work just fine though an I2P outproxy.

But, remember to use one browser just for I2P. Never let it touch the normal clearnet. Going through an outproxy is fine though.

found it. theres an outproxy in i2p+ by default. Why would that be there? I thought the entire point was to keep traffic internal to the i2p network

I wonder why i2pd has a lower rate than i2p+. Does it just have a different way of evaluating that metric?

I'm continuing to experiment with this and torrents. I migrated it back to my server and tried taking it out of the container since I was running the container rootless when I first tried it there. rootless podman containers supposedly have issues with UDP connections. The torrenting speed in qbittorrent and snark are a little better, but still topping out at only about 200k so there's still more room for tweaking here.

Right now, things seem more stable with I2P+ than I2PD, but I'm blaming that squarely on my own ignorance in how to properly tune this setup.

I'm really excited to see how that emissary project grows too, but I'm not sure I trust it just yet. I'm going to wait for others who actually know what they are doing to vet the project as well as SSU2 support to finish before I give it a try.

i assumed which is why i brought up the i2cp thing earlier, but wasn't sure if you had it in some other container or something in the other machine that'd be blocking connections, must've had something going on with the firewall somewhere

weird about the wrapper, never tried it on alpine linux so maybe there's a workaround or the i2prouter script could be modified. jbigi i've had to compile to get it to work right at least with i2p+ sometimes. if you don't see libjbigi.so in your /i2p directory then you'd just need to compile it

the devs are around here, quickest answer to get the wrapper to work right would be to pop in to irc2p

pretty good breakdown, if you end up messing around in both you'll find they can be good for different things. i2p+ is more selective and wants to put resources to things like service tunnels, it happens to be very good for hosting things in i2p and if you want to do other stuff on top of torrents/eepsites. i2pd is bare bones and uses little resources, usually very fast if tunnel build success is good, good for torrenting. it has its own trade offs. i watch the memory usage on that one closely. I like i2pd a lot for certain things but i've learned you do need to be careful with it at times and set conservative limits

i2p+ will usually see build success +70%, i2pd should hang somewhere around 30-50, lower with floodfill. In practice though i2pd should be running great at 30-50, but if it drops under 10 you get problems.