Someone explain to me why the following combination of steps wouldn't solve all problems - for both content publishers, and RSS app creators.
Content publishers: Update the RSS feed generator to include the ads associated with the post. Write tools for dynamic ad insertion that actually updates the syndicated feed.
RSS App creators: Build ad networks that work with both ad buyers and content creators to match content-relevant ads, and either replace the dynamic in-post ads (and share revenue), or add additional intra-post ads.
Someone explain to me why this couldn't work with the existing technology stack - no new protocol, or client-side changes required.
It wouldn't work because it doesn't support the intrusive tracking (including "telemetry" and "analytics"), giant slide-over windows that obscure the content, repeated pop-ups demanding your email address, announcements that "you have 1 free article remaining unless you pay for a subscription," social media integration buttons, solicitations to "download our mobile app," CAPTCHA loops, "DDoS protection" delays and redirects, ad-blocker-blockers and autoplaying videos that are integral to web sites in 2020.
Also it is too lightweight in terms of cpu, memory, network and power usage, so it wouldn't push users to upgrade to the latest and greatest hardware (and data plans) every year just to maintain the same performance they had last year.
Content publishers: Update the RSS feed generator to include the ads associated with the post. Write tools for dynamic ad insertion that actually updates the syndicated feed.
RSS App creators: Build ad networks that work with both ad buyers and content creators to match content-relevant ads, and either replace the dynamic in-post ads (and share revenue), or add additional intra-post ads.
Someone explain to me why this couldn't work with the existing technology stack - no new protocol, or client-side changes required.