IRC/IRCS tracker(less) protocol

[SoniEx2]

I'm currently working on using IRC as part of bittorrent, similar to how you'd use a tracker.

You'd have tracker URLs like ircs://example.org/%23channel,%23channel%20password,password or ircs://example.org/user,user or whatever, the torrent client would connect to the IRC network, JOIN whatever comes after the / (e.g. JOIN #channel,#channel password,password or JOIN user,user - the latter is fine and it should make no attempt at handling such errors), then NOTICE what comes after the / up to the first space with the special IRC message to make this all work (e.g. NOTICE #channel,#channel :[...] or NOTICE user,user :[...]).

It should send a new such NOTICE every time it sees a JOIN, with at least a 15 second cooldown, or whenever an event has occurred. If another JOIN happens during time-out, it should send a new such NOTICE after cooldown. The user may also instruct the client to send a new such NOTICE, overriding the cooldown. The client should not send any IRC commands faster than once every half a second, to avoid getting hit with flood limits.

The contents of the IRC message are a CTCP, using an announce message structure similar to that of BEP 15, but omitting the connection and the transaction IDs as those aren't necessary here, and base64-encoded. The CTCP message is DCC TRANSSEND [base64-encoded announce]. No provision for extensions is made, other than the action field, which should be 1 for ipv4 announces, and 2 for ipv6 announces.

Clients receiving the announce/TRANSSEND should use the IP address as specified in the announce, but are allowed to use the hostname as sent by the IRC network. Note, however, that many IRC networks employ cloaking so the IRC hostname isn't always available.

Clients should send one TRANSSEND per IP address. If a client has an IPv4 and an IPv6, it should send 2 TRANSSENDs: one for IPv4, one for IPv6.

Motivation

While this seems like a general-purpose bittorrent tracker protocol, I mostly intend for it to be used as an alternative DCC mechanism for existing IRC users. But if it's worth doing, it's worth overdoing.

[arvidn]

Isn’t there a way to query user’s IPs directly in the IRC protocol?

It would seem more reliable to have the server report IPs than have peers report their own IPs. Partly because it may be hard to know ones own IP, but it also makes it harder to “spam” fake peers, or victim’s IPs in a DOS attack.

I’m not very familiar with the IRC protocol, I may have misunderstood something. Could you post a Link to some authoritative protocol specification?

[SoniEx2]

Yes - if you are the user.

No - if you are another user. You can sometimes get a hostname but not always. Many servers employ "cloaking" which hides or obfuscates the hostname.

And if the existing DCC mechanism doesn't get used for DDoS, why would this be any different? BT connection packets (TCP and uTP) are tiny compared to the IRC connection + DCC TRANSSEND payload, this would only be effective as a DDoS attenuation mechanism if anything. ;)

[arvidn]

I got the impression that idea was that the bittorrent client would join the IRC channel and to be a user.

Again, I'm not very familiar with the IRC protocol, but the fact that bittorrent has many peers might make the magnification greater than regular DCC.

btw, I'm intrigued by this idea. I think it's especially cool that you could have new peers pushed to you

[SoniEx2]

You can read more about IRC here: https://tools.ietf.org/html/rfc1459 and here: https://ircv3.net/ and here: https://freenode.net/kb/answer/cloaks and here: https://snoonet.org/posts/2018/11/22/important-changes-to-snoonet-and-a-partnership-with-irccom/ (in particular note how this applies to unregistered users)

PEX seems to provide mitigations for untrusted peers http://bittorrent.org/beps/bep_0011.html / http://bittorrent.org/beps/bep_0040.html maybe we should use them here?

I'd honestly expect your average IRC network (like freenode) to straight up ban these bittorrent/IRC clients if a torrent gets too big. This alone is enough to mitigate the risks. Dedicated tracker IRCs should verify/filter the messages (and this is where SCTP would come in handy because you'd be able to see all peer addresses but smh we don't have SCTP in the wild yet so I guess you'd just need to use multiple separate connections? :/). If a torrent gets big enough that the amount of messages overwhelms new clients, tough luck, use a proper tracker rather than a DCC mechanism I'm trying to pass off as a pseudo-tracker so ppl can't prevent me from adding it to IRC. :V

[yarikk]

Please note that this doesn't really make it "tracker-less" but effectively replaces the protocol, shifting the role of trackers to the IRC servers, with similar scalability and administrative implications.

[SoniEx2]

That's a valid point. IRC tends to scale well, at least, so it shouldn't be too big of an issue.

It would be useful if the channel name was semantic, and perhaps used a non-# prefix. This would prevent using such bittorrent clients with conventional IRC networks. Other than that, just the usual IRC features need to be used: channel mode +n (client must join to send message) should be off (altho this isn't that critical), the server shouldn't tell the client about other users in the channel (a common feature of IRC daemons, but might need some tweaking), IPv6 servers probably shouldn't link to IPv4 servers altho not sure how much of an issue this would be in practice, and the server may want to apply some filtering to client-to-server announces, just like existing trackers.

These are all more-or-less standard features. It shouldn't be too hard to setup a demo/MVP...

This also has the benefit of automatically supporting tor/i2p, as exposing IP addresses (in the :nick!user@host message prefix) is a standard IRC feature, but those can also be hostnames.