Future idea: PIN-based discovery + hole punching for easier remote access - Printable Version +- Jellyfin Forum (https://forum.jellyfin.org) +-- Forum: Development (https://forum.jellyfin.org/f-development) +--- Forum: Feature Requests (https://forum.jellyfin.org/f-feature-requests) +--- Thread: Future idea: PIN-based discovery + hole punching for easier remote access (/t-future-idea-pin-based-discovery-hole-punching-for-easier-remote-access)

Future idea: PIN-based discovery + hole punching for easier remote access - DNAmaster10 - 2025-09-28 Hi there, As mentioned in the title, I'm posting this as more of a 'future suggestion' as this is largely speculative and probably unrealistic for the time being. I thought it worth documenting as a potential long-term idea that might fit Jellyfin's philosophy. I'll pre-empt this by stating that I do not possess the expertise to come anywhere close to being able to implement this, so apologies if I'm overly simplifying a rather complex topic. The Problem Currently, alternative services such as Plex make server discovery significantly easier for users outside the network the server is hosted on. In Plex's case, port-forwarding isn't even required for a server to be visible outside of someone's home network thanks to their relay servers, which allow home-hosted servers to stream content to the client via their relay service. While port-forwarding and the like is trivial for someone with even a small level of knowledge about how networking works, the additional configuration steps for Jellyfin are often cited online as being a barrier to entry. In an ideal-setup for external server access, Jellyfin usually works best with a domain, port-forwarding, and an SSL certificate to allow HTTPS traffic. In Jellyfin's case, relay servers are unfortunately not a viable option. They're incredibly expensive to operate, even with bandwidth restrictions (Such as Plex has), and generally speaking go against the open-source, decentralized philosophy that Jellyfin operates on. Proposed Concept Drawing inspiration from the Torrent protocol, I'd like to raise the idea of implementing a fully optional and decentralized DHT-like system that Jellyfin could adopt, utilising pin-based discovery and hole-punching. PIN-based discovery system A pin-based discovery system could operate as follows from the user's perspective: Each Jellyfin server could register a short PIN (e.g. 1234) with a decentralized network.  The network could be an opt-in system built-in to each Jellyfin server. By opting in, your Jellyfin becomes part of the decentralized network. A client only needs to enter that PIN once; The system resolves it to the server's current public IP / Domain automatically. This would operate similar to a distributed phone book, in a similar spirit to BitTorrent DHT or tracker networks, but lightweight. This removes the friction of telling non-technical users to “Type in mydomain.com:8096”, and would also mean server-owners don't have to think about setting up a Domain with a changing public IP. Hole punching for direct connections The larger and probably much more complex suggestion I'd add to this would be the use of hole punching for direct streaming connections. Most home internet setups put your devices behind a router or NAT (Network Address Translation). NAT makes outbound connections easy, but it blocks unsolicited inbound connections - Which is why remote access usually needs manual port forwarding. Hole punching is a technique that gets around this by having two devices (in this case server and client) each send outbound packets toward the other at the same time. Because the router sees outbound traffic, it creates a temporary mapping in its NAT table - And that 'hole' allows the other side's packets in. Hole punching is already widely used across many services. WebRTC (video calls, e.g. in Zoom, Discord, Google Meet, etc) often rely on hole punching for direct media streams. BitTorrent, where peers exchange addresses via trackers/DHT and then use hole punching to connect directly, even without port forwarding. VoIP (Skype, SIP clients, gaming voice chat) use NAT traversal as a standard trick to avoid forcing every call through a central relay. In theory, the same technology could be used in Jellyfin. A Jellyfin server connects to the decentralized network and registers its chosen PIN (e.g. 1234). The server keeps a tiny keepalive running, so the network can always send it coordination messages. The client would then ask the network, “Where is server 1234?”. The discovery network replies with the server's current public IP and port. The discovery network notifies the server that a client is trying to connect, passing along the client's public IP/port. Both sides begin sending small outbound UDP packets toward each other. If hole punching succeeds, NAT routers on both sides see outbound traffic and open temporary mappings. The client and server now have a direct peer-to-peer link, with no port forwarding needed. If hole punching fails, the user can just receive an error saying “This server requires port-forwarding to function” or similar. Where a server already has port-forwarding and the like set up correctly, this type of connection could be prioritized over this new system.  While hole punching does not always succeed, I'd estimate that a system like this could eliminate the need for port-forwarding, domain setup, etc, in at least 75% - 85% of setups where NAT traversal is possible. From the user's perspective, it would elevate Jellyfin to be nearly on-par with Plex and other services when it comes to ease of use and setup. Jellyfin would be a “one-click install” server which still allows for direct port forwarding, domains, etc.  Challenges The way I've worded this above makes this sort of system sound trivial. The reality, though, is that a project of this scale would require an immense amount of technical understanding about networking protocols, general programming, and would also probably take quite a while to 'get up off the ground'. Distributed networks aren't something that can just be 'set up once'. They rely on enough people utilising the feature to make it worthwhile, and would likely require at least a few early-adopters to kick-start the network. Accomplishing this in browsers would probably be more difficult, too. The technology does exist through WebRTC, but Jellyfin would then need to support WebRTC-based streaming in addition to current HTTP-based streaming, and both services would need to be maintained side-by-side going forward. Concluding Thoughts I do believe that a system like this would elevate Jellyfin to being on-par with Plex for the vast majority of users in terms of ease of use and setup for typical home users. For mobile, hotel, corporate, or campus networks, success drops significantly. But hole punching + PIN discovery would cover the majority of Jellyfin users without requiring port forwarding. I'll reiterate that I'm posting this as more of a 'future suggestion' than a solid feature proposal. I'm humbled by the level of technical knowledge that would be required to implement this in practice, and something like this is not likely within Jellyfin's top priorities at present.