RFC: Ads.txt chaining

ads.txt

# Sample publisher ads.txt
somenetwork.com, 1234, DIRECT
another.org, 4455abc, RESELLER

# !include https://managednetwork.com/managed.ads.txt.php?id=123

managed.ads.txt

# Included ads.txt from initial site
advertiser.com, 9999, RESELLER
network.co.uk, 123400, RESELLER

Justification

Chaining ads.txt files would make managing large amounts of clients much easier, as it's currently very impractical to continually request ads.txt updates from all of our clients. Growing companies such as ours that are regularly adding new network partners face the challenge of reaching out to all of our publishers to get new lines in.

Chained ads.txt files would allow us to manage the lines relevant to our partnership for the client. The security behind this is definitely debatable as the publisher is usually in a position of having to trust, somewhat blindly, that the reselling partner is working with honest networks for the selling of their inventory. Chained ads.txt files are no different apart from the fact that the reseller can update the lines without the acknowledgement of the publisher. As trust has been passed to the reseller in the management of some portion of the publisher's inventory, the risk of having the lines updated without explicit approval is negligible.

Functionality

Through an include statement of some kind, the lines from a remote ads.txt file could be requested and included in the processing of the original site. The format of the remote ads.txt file would of course follow the existing ads.txt specification.

The actual syntax isn't important, and the $ prefix was simply to denote an instruction, rather than another demand line or comment.

The include statement is contained within a comment so that older parsers/fetchers don't break on the statement (thanks @dec5e). The prefix to the include statement, !, is arbitrary and simply there to denote an instruction rather than a normal comment. A friendly parser might try to only recognise the following pattern, for instance (per-line):

^\s*#\s*!include\s+https?:\/\/.+

Chaining would have to work in a way that many ads.txt include statements could be followed, as networks may utilise the same method of linking. Ads ads.txt are handed in an offline manner, in terms of the selling process, it shouldn't matter how many links there are in a chain.

If you replace $include with #include like this:

#include https://managednetwork.com/managed.ads.txt.php?id=123

it would help to gradually start using this feature without breaking old ads.txt scrapers - they would ignore this line as a comment.

@dec5e Good point! Graceful fallback. It'd still fail of course as the new lines wouldn't be read on older fetchers, but at least parsing wouldn't fail. The only problem with that approach is that regular comments could include the "include" word as part of a regular comment, and then fail. Eg:

# My ads.txt
#
# This ads.txt was generated by some bot, and it should
# include the correct amount of lines

So for cases like that it'd be tricky. Maybe best to still have it prefixed inside the comment?

# My ads.txt
somenetwork.com, 1234, RESELLER

# !include https://site.com/ads.txt