I fully agree with @deeplowās assessment, nothing really bad happened. @cayce got a bit annoyed at @enmusā rapid feedback and posted some unnecessary personal remarks. Thatās why we slowed down the thread and asked @cayce to please stop that. It appears heās cool with it as is @enmus.
Definitely condescending (in violation of standards)
Discouraging requested contributions to an open source project is about as ābadā as one could imagine
I think thereās some typos here, more like:
No @mod asked such a thing publicly nor privately, nor am I cool with āitā (aka biased moderation valuing FUD, feelings and dis/misinformation above contributions) which leads to a complete wash-out of contributed work. To foster community involvement, either uphold all of the standards for the betterment of the community or none.
Can an individual be expected to take this work effort seriously after reading the overflowing abundance of misguided/misinformed opinions/feelings within a technical thread? Despite being the OP; I sure canāt
If after an entire week of all this dribble, anyone would actually like to use this project, please just post a message in-thread something like: āHi cayce, Iād like to give it a tryā and, Iāll message via PM.
If not, I couldnāt fault you; not sure Iād bother with anyone taking into account all the FUD/dis/misinformation and attempted character assisinations.
Spent the entire day trying this out, shit donāt work unfortunately.
tried installing everything via the script and also tried doing everything on my own following more or less the instructions on the script. it donāt work in both ways, the closest Iāve been to making it work was doing it by myself. But in both cases the connection either timed out or straight up said that it wasnāt possible to reach the website.
I tried all I could but nothing works, my best result with this was a āfirewalledā network status that I couldnāt even solve since the next time I restarted the qube i2pd just stays on āunknownā network status.
I hope someone is able to figure this shit out cause I certainly canāt.
concept should work in theory but I think some firewall changes happened during recent times both in qubes or the i2p project and it doesnāt work anymore, even just trying to start it out inside a whonix workstation doesnāt work anymore.
Sounds to me like you arenāt giving the i2p daemon enough time to set up the required tunnels ⦠you just need to wait for sometime for them to be established.
Iāve got this working through every NetVM (sys-net, sys-firewall, sys-ips, sys-vpn, sys-whonix) and every variation of chaining (including them all).
Sadly , I wonāt be able to support further in this thread because itās been throttled due to the emotive nature of @mods and the forum in general.
My PMs are open for now if you want help walking you through it.
Hello there sorry for not having answered before, still trying to take time away from screen.
It is syntactically correct, where the suggestion in doc above is to put all user policies (that might conflict with each other), if possible, under 30-user.policy instead of another policy file.
Logic there, as for recent whonix debates for which policy file shoukd be modified/created is that not all users will think of checking in other lower numbered down files, where 30-user.policy should be used if possible (and relevant), otherwise creating confusion (as seen in the past on why things donāt work and where users only check under 30-user.policy).
And to be honest, I would have to check Qubes internals to know which one of 30-user.policy or 30-user-networking.policy would be applied first, since they share the same number (30). I think this will lead to problems in the future if not already for some users.
I know, I know, I should test this. As of now I havenāt neither tested unmanās either but will try in the future both for sure.
I just am in love with public RPM spec files and associated rpms and repos for this. So convenient and so easy to understand and follow flow of deployment, application and learning. You donāt like it? Just uninstall RPM, delete appvm and parent template.
so let me get this right, this DOESNāT allow me to chain netvmās to the i2p netvm, correct? Iāve been looking for a way to make an i2p netvm for aaaaaaages
Hi @cayce
Great to see your contribution. Well, I havenāt yet seen it - is it still
private?
Iāve only skimmed this thread - the (literal) noise has made it
difficult for me to pick out whatās important.
If I understand - you have produced an i2p proxy with a nice GUI
control. My simple solution was set to provide an i2p node - the in.sh
script can be used to allow inbound traffic to pass through the qubes
networking stack.
It would be great if we could combine these and package them to provide
a simple means of installing and setting up an i2p node available to
other qubes.
If you can give me access to your repo that would be good.
PM me if you want to discuss off list.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
@cayce I glanced the through code. It is nice and simple. Havenāt actually tried it out on my actual system yet.
A couple of things:
Would you consider switching to using Fedora instead of Debian? For one, Qubes defaults to using Fedora for most of its VMs. And two, Debian has a habit of shipping extremely old/EOL packages which isnāt ideal for security. It shouldnāt be too hard to just convert this to Fedora.
I see that you are doing make install for i2pd-qt. The problem with this is that updating i2pd-qt will then need to be done manually instead of being done automatically by the qubes updater. There are a couple of potential workaround for this:
Package i2pd-qt using something like COPR or OBS and install the packages instead. I understand that this is a lot of extra work and might be out of scope, and you then would also need to be a package maintainer.
Use the Flatpak package and add a systemd service to automatically update it. This would require just using a normal VM for sys-i2pd rather than a disposable VM, as we would not want the updates to disappear every reboot. Since sys-i2pd will always be on, we can be reasonably sure that the custom systemd service will keep everything up to date.
Debian just hasnāt been the same since Ian left us. I really hope that heās in a better place ā¦
Iām not terribly impressed with fedora either, my current preference is nixOS. That said, I likely will not bother with a fedora based version because IMO itās a moot point, this is a service qube based on a minimal template. If oneās threat model is so sharp as to need to defend against unpatched debian 0-dayz, this is not the correct solution. Despite falling off IMO, debian still patches quickly.
Youāre right, it wouldnāt be too hard @ all since, Iāve taken the time to do the hard bits. If anyone needs a fedora version, Iāll be happy to work on it after donations have been made.
The GUI project is an official i2p project thus, in due time, itāll be added to the official i2p repo. At that time, Iāll modify the project to leverage the repo/binary package. Iām not planning to package anything unless someone wants to make contributions to do so.
Regarding flatpakās, Iām not a fan nor would any hackery to create āauto-updatingā be worth-while IMO as, it would be outside of the Qubes update mechanism so, not very different from the build approach.
I spent the day with this user on PM and, it turned out the project was working as expected but, the user was not being patient enough to allow the necessary tunnels to be created.
Fact is, both onion & garlic routing have been fielding serious blows lately so, I advise anyone trying to use this project or any i2p projects to check the latest sub-reddit to verify status/expectations.
Instead of confirming success/misunderstanding here ...
They went ahead and posted a āhow-toā install i2pd