Merge branch 'main' into 3-24-features

Author: aram356

.github/workflows/format.yml

@@ -0,0 +1,42 @@
+name: "Run Format"
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+# Check formatting with rustfmt
+jobs:
+  format:
+    name: cargo fmt
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Cache cargo dependencies
+        uses: actions/cache@v4
+        with:
+          path: |
+            ~/.cargo/bin/
+            ~/.cargo/registry/index/
+            ~/.cargo/registry/cache/
+            ~/.cargo/git/db/
+            target/
+          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
+
+      - name: Set up rust toolchain
+        uses: actions-rust-lang/setup-rust-toolchain@v1
+        with:
+          components: "clippy, rustfmt"
+          toolchain: 1.83
+
+      - name: Add wasm32-wasi target
+        run: rustup target add wasm32-wasip1
+  
+      - name: Run cargo fmt
+        uses: actions-rust-lang/rustfmt@v1
+
+      - name: Run cargo clipply
+        run: cargo clippy --all-targets --all-features
+

.github/workflows/test.yml

@@ -0,0 +1,39 @@
+name: "Run Tests"
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    name: cargo test
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Cache Cargo dependencies
+        uses: actions/cache@v4
+        with:
+          path: |
+            ~/.cargo/bin/
+            ~/.cargo/registry/index/
+            ~/.cargo/registry/cache/
+            ~/.cargo/git/db/
+            target/
+          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
+
+      - name: Set up Rust tool chain
+        uses: actions-rust-lang/setup-rust-toolchain@v1
+        with:
+          toolchain: 1.83
+
+      - name: Add wasm32-wasi target
+        run: rustup target add wasm32-wasip1
+
+      - name: Setup Viceroy
+        run: cargo install viceroy
+
+      - name: Run tests
+        run: cargo test

Cargo.lock

@@ -7,7 +7,6 @@ edition = "2021"
 # Otherwise, `publish = false` prevents an accidental `cargo publish` from revealing private source.
 publish = false
 license = "Apache-2.0"
-license-file = "LICENSE"
 
 [profile.release]
 debug = 1
@@ -26,4 +25,5 @@ futures = "0.3"
 tokio = { version = "1.0", features = ["sync", "macros", "io-util", "rt", "time"] }   
 url = "2.4.1"
 config = "0.15.11"
+handlebars = "6.3.2"
 chrono = "0.4"

Cargo.toml

@@ -0,0 +1,42 @@
+**What is Trusted Server POC?**
+The  POC or proof of concept is to prove the technical feasibility of managing advertising for publishers on the server. It uses the edge cloud like Fastly, Akamai etc. to initiate ad requests, integrate prebid server, receive ad response and stitch the ad on the server before sending the page to the client browser. In addition it showcases the capabilities to maintain a key-value (kv) store to use critical data needed by a publisher for advertising and the capability to uniquely identify a user agent using a persistent id
+
+**Is this ready for use by publishers?**
+NO. It is NOT a version 1.0 and is NOT ready for use by a punisher in its current form.Its a proof of concept (POC). The purpose is to showcase technical feasibility of executing publisher  advertising functions server side and initiate industry effort to define and build an MVP or version 1.0 that is ready for use by publishers
+
+**Why did Tech Lab build the Trusted Server POC?**
+Today all of the publisher advertising is managed using third party providers, telemetry and capabilities available on the browser. New privacy initiatives and proposals by all major browsers are severely restricting most third party activities and telemetry used in advertising thus making it less and less effective, for e.g. third party cookie deprecation. Moreover, ad blocking is only growing worldwide. Managing ad requests on the edge cloud offers several advantages and better controls to the publisher, for e.g. device and user identification,enabling third parties with better control, managing privacy and improving page performance.
+
+**Will the Trusted Server work for mobile in app advertising?**
+The POC is designed for browsers and the initial trusted server focus is to support browser traffic. A second phase will focus on mobile apps. 
+
+**Is the Trusted Server free?**
+YES. The trusted server will be free and open source and offered under Apache 2.0 license terms.
+
+**Does the POC integrate with my CMS?**
+As of today, it doesn’t. This is a simple POC where we are hosting the very basic HTML/JS content inside the Trusted Server application itself. We will begin to release modules and reference architecture as the project moves forward. We’d also love contributions from our community on this front! 
+
+**What is the vision for MVP or version 1.0?**
+Tech Lab envisions the MVP to incorporate capabilities to make a valid Open RTB ad request using a prebid server and process the response for native, display and video ads. Our current plan for MVP version is that it can support addressability (user/device signals, ID solutions, other audience and targeting solutions), privacy management (CMP  execution, GPP and TCF strings), CMS integration, Publisher Ad server integration and prebid server integration. We look forward to the industry to help develop the MVP definition. 
+
+**Will Tech Lab build all the capabilities?**
+NOT all the capabilities. Tech Lab will build and support core services to enable existing publisher and adtech companies to build their own modules to support publisher advertising capabilities. 
+
+**Does the Trusteed Server preclude using third party tags?**
+No, it does not. You should be able to begin migrating certain modules and parts of your content and experience as you go, without a forklift upgrade. We plan to support server side tagging capabilities to enable third party support.
+
+**Why are you only using two vendors in the POC?** 
+Fastly and Equativ volunteered time and resources to us and they fit the technical needs and requirements for Trusted Server. For the sake of getting to market ASAP, we chose to double down on these two partners. We do not play favorites or have any financial incentive with these two companies and will begin implementing on other partners in the near future.  Any ad exchange supporting prebid server requests should already find support. We will prioritize modules for other edge cloud providers based on industry priorities
+
+**How will this project be managed?**
+Tech lab has created the ‘Trusted Server Taskforce’ to manage the requirements and roadmap for the project. We will maintain a core engineering team to build based on task force priorities and invite community contributions, especially third party providers to build their tags and modules for publishers.
+
+**How will you support the publishers planning to implement?**
+Yes! As of today we will be providing community support on a best effort basis as we scale up the architecture and use cases. We will do our best to respond to inquiries in the Github project as quickly as we can. 
+
+**How will it work for medium size publishers using managed Word Press hosting (Ghost)?**
+Yes. As long as your managed service provider can separate the edge from the CMS, They should be able to run trusted server. Some work may be necessary and we look to the community for contributions in defining and building for it.
+
+**How will this comply with Privacy regulations?**
+The trusted server will have modules to support Consent Management Providers (CMP) and send the GPP or TCF string as required in the ad request.
+

FAQ_POC.md

@@ -0,0 +1,25 @@
+# Project Governance for The Trusted Server
+
+The Trusted Server project will be governed as an open-source initiative, in accordance with the established guidelines of the IAB Tech Lab Open Source initiative. However, certain key distinctions apply:
+
+* The Trusted Server Task Force shall be responsible for the definition of requirements and the project roadmap.
+* The Task Force shall adhere to the working group rules and procedures of the Tech Lab.
+* The Trusted Server Development Team shall oversee engineering development and releases.
+
+## The Trusted Server Task Force
+
+A dedicated Task Force has been constituted by the Tech Lab to oversee the requirements and roadmap for the Trusted Server initiative. The core mandate of the Task Force is to review, approve, and prioritize proposals, issues, and pull requests submitted by the community for the Trusted Server.
+
+The Task Force shall adhere to the working group rules and procedures of the Tech Lab for decision-making and management of the Trusted Server roadmap, with one exception: in recognition of the project's open-source nature, a formal public comment release period will not be instituted. Software releases will be conducted on a continuous basis.
+
+The Task Force will convene biweekly, and detailed meeting minutes will be meticulously maintained within the Trusted Server GitHub repository.
+
+## The Trusted Server Development Team
+
+The Development Team shall be responsible for the evaluation of technical feasibility of requirements, the definition of system architecture, and the construction of the Trusted Server in alignment with the roadmap established by the Task Force. The team composition is as follows:
+
+* **Project Release Manager:** This individual holds ultimate responsibility for project development and possesses 'write' access to the repository.
+* **Committer:** This developer possesses 'write' access to the repository and is responsible for implementing final changes.
+* **Developer:** This contributor contributes to the project through code or documentation and may assume further project management responsibilities.
+
+The Development Team shall be responsible for the development and release of the Trusted Server and will establish its own sprint and meeting schedule.

ProjectGovernance.md

@@ -46,6 +46,8 @@ brew install fastly/tap/fastly
 fastly version
 ```
 
+:warning: fastly cli version should be at least v11.1.0
+
 #### Create profile and follow interactive prompt for pasting your API Token created earlier:
 ```sh	
 fastly profile create
@@ -91,7 +93,7 @@ git clone [email protected]:IABTechLab/trusted-server.git
 :information_source: Note that you’ll have to edit the following files for your setup:
 
 - fastly.toml (service ID, author, description) 
-- Potsi.toml (KV store ID names) 
+- potsi.toml (KV store ID names) 
 
 ### Build
 

README.md

@@ -12,10 +12,8 @@ service_id = "q9waEnTgJfqQV1a0cYOuo3"
 [scripts]
 build = """
     cargo build --bin potsi --release --target wasm32-wasip1 --color always &&
-    ln -fs wasm32-wasip1 target/wasm32-wasi
 """
 
-
 [local_server]
     [local_server.backends]
         [local_server.backends.equativ_ad_api_2] # FIX ME: must match config

fastly.toml

@@ -9,3 +9,11 @@ server_url = "http://68.183.113.79:8000/openrtb2/auction"
 counter_store = "jevans_synth_id_counter"
 opid_store = "jevans_synth_id_opid"
 secret_key = "potsi"
+# Possible values
+#   - "client_ip"
+#   - "user_agent"
+#   - "first_party_id"
+#   - "auth_user_id"
+#   - "publisher_domain"
+#   - "accept_language"
+template = "{{ client_ip }}:{{ user_agent }}:{{ first_party_id }}:{{ auth_user_id }}:{{ publisher_domain }}:{{ accept_language }}"

potsi.toml

@@ -1,2 +1,3 @@
-pub const SYNTH_HEADER_FRESH: &str = "X-Synthetic-Fresh";
-pub const SYNTH_HEADER_POTSI: &str = "X-Synthetic-Potsi";
+pub const SYNTHETIC_HEADER_FRESH: &str = "X-Synthetic-Fresh";
+pub const SYNTHETIC_HEADER_POTSI: &str = "X-Synthetic-Potsi";
+pub const SYNTHETIC_HEADER_PUB_USER_ID: &str = "X-Pub-User-ID";