Tiekoetter.com Forum

I have extended the IPv6 access via AS208694 to redlib.tiekoetter.com and nitter.tiekoetter.com

Just checked it. It was actually Twitter that was down and not the Nitter instances. It is still a bit flaky but so is Twitter itself right now.

It looks like Nitter got nuked.
https://status.d420.de/
My instance only has cached results available. I will have to take a look later today.

Hello,
please post your feedback / issues / comments regarding IPv6 access via AS208694 (www.as.tiekoetter.net)

I would appreciate your input to evaluate the functionality of AS208694 for future adjustments.

I have implemented IPv6 access via AS208694 for searx.tiekoetter.com, invidious.tiekoetter.com, wikiless.tiekoetter.com and this Forum.

AS208694 is operated by me and serves as another layer of control. Currently only IPv6 is possible as IPv4 is far too expensive for an individual to get. The IPv6 access is terminated at the same server, it is just routed differently. It works in conjunction with the current IPv6. I may expand this to the other services in the future.

More information about AS208694 can be found here: www.as.tiekoetter.net

For the missing features please refer to the GitHub repository of the developer of Nitter: https://github.com/zedeus/nitter

The "following users" suggestion is on the roadmap (account system) I don't know how far this feature is in development. You can open an issue there regarding the NSFW options.

Thanks for the feedback! I hope my hosted services continue to be useful to you and others!

The Nitter instance is now fully restored again.

After a bit more testing and one full day of evaluation Wikiless is now restored.

The aggressive caching didn't really help. I added Anubis on top of Wikiless and after a few minutes it completely removed the rate limit on the back-end.
Meaning JavaScript is now required for Wikiless but the barrage of bot requests gets filtered out. In my opinion a fair trade off.

Shoutout to Anubis. This software is incredible at stopping bots/scrapers https://github.com/TecharoHQ/anubis

I have implemented very long caching rules. This should mitigate the hammering of the wikipedia.org servers. From my usage when encountering an "INVALID_HTML" page (429 from upstream) refreshing a few times will get the page eventually. These cached pages are considered fresh for 6 hours and stale for up to 1 day, afterwards they are discarded if no other user requests the page in the meantime.

This is not optimal but a good enough intermediate solution.

I guess Wikipedia has finally decided to block my Server.

The back-end reports 429 from the wikipedia.org servers.

Currently Wikiless doesn't support proxy servers. I would have to fork Wikiless and implement it myself for it use my proxy back-end. I may have to look into this in the future.

The Nitter instance is currently degraded as the accounts used in the back-end are rate limited. This is, from what I can view, due to legitimate requests.

Meaning I have to add new accounts, which takes a bit of time.

I have upped the Anubis difficulty from 4 to 5 in the meantime.

More specifically the "X25519MLKEM768" group if the client supports it. Fallback are still the normal "X25519" and "SecP384r1" groups if the client doesn't support the MLKEM group.

Why is this important?
Quantum computing could break standard cryptography when it matures. These Module-Lattice (ML) Key Encapsulation Methods (KEM) are designed to withstand future quantum computing attacks.

What does "X25519MLKEM768" do?
As the name might suggest it combines both mechanisms of "X25519" and "ML-KEM-768" forcing an attacker to break both mechanisms to break the cryptographic key exchange.

Drawbacks?
As this is using both the standard "X25519" mechanism and the "ML-KEM-768" encapsulation mechanism it is more computationally expensive as the "X25519" standalone. This should be negligible on modern systems.

You can check if your Browser supports this by opening the browser console and selecting the security tab. Something like this should be shown:

Regarding Invidious: YouTube is currently A/B testing disabling DASH. Invidious uses DASH for the video streams. YouTube wants their in-house protocol, SABR, to be the new default. Some mitigations are now in place to get DASH back but consider Invidious unstable for the foreseeable future as YouTube will likely disable them sooner or later as well.

https://github.com/iv-org/invidious-companion/issues/60

URL: https://redlib.tiekoetter.com

Alternative front-end for Reddit

Source code: https://github.com/redlib-org/redlib

URL: https://nitter.tiekoetter.com

Lightweight front-end for Twitter

Source code: https://github.com/zedeus/nitter

URL: https://wikiless.tiekoetter.com

Alternative front-end for Wikipedia

Source code: https://codeberg.org/orenom/Wikiless (Mirror: https://github.com/Metastem/wikiless)

URL: https://lt27.de

URL Shortener

Source code: https://github.com/YOURLS/YOURLS

URL: https://bin.tiekoetter.com

Minimalist, open source online pastebin where the server has zero knowledge of pasted data. Data is encrypted/decrypted in the browser using 256 bits AES.

Source code: https://github.com/PrivateBin/PrivateBin

URL: https://invidious.tiekoetter.com

Lightweight/alternative front-end for YouTube

Source code: https://github.com/tiekoetter/invidious

URL: https://searx.tiekoetter.com
URL (Tor): http://searx3aolosaf3urwnhpynlhuokqsgz47si4pzz5hvb7uuzyjncl2tid.onion

A privacy-respecting, open metasearch engine

Public instances: https://searx.space

Source code: https://github.com/tiekoetter/searxng