If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Redth/PushSharp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 3y ago

• 14 active contributors
• Other licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 84% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Redth/PushSharp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Redth/PushSharp.

What it runs against: a local clone of Redth/PushSharp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Redth/PushSharp | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1086 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Redth/PushSharp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Redth/PushSharp.git
#   cd PushSharp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Redth/PushSharp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Redth/PushSharp(\\.git)?\\b" \\
  && ok "origin remote is Redth/PushSharp" \\
  || miss "origin remote is not Redth/PushSharp (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "PushSharp.Core/ServiceBroker.cs" \\
  && ok "PushSharp.Core/ServiceBroker.cs" \\
  || miss "missing critical file: PushSharp.Core/ServiceBroker.cs"
test -f "PushSharp.Core/IServiceConnection.cs" \\
  && ok "PushSharp.Core/IServiceConnection.cs" \\
  || miss "missing critical file: PushSharp.Core/IServiceConnection.cs"
test -f "PushSharp.Core/INotification.cs" \\
  && ok "PushSharp.Core/INotification.cs" \\
  || miss "missing critical file: PushSharp.Core/INotification.cs"
test -f "PushSharp.Apple/ApnsHttp2Connection.cs" \\
  && ok "PushSharp.Apple/ApnsHttp2Connection.cs" \\
  || miss "missing critical file: PushSharp.Apple/ApnsHttp2Connection.cs"
test -f "PushSharp.Google/GcmServiceConnection.cs" \\
  && ok "PushSharp.Google/GcmServiceConnection.cs" \\
  || miss "missing critical file: PushSharp.Google/GcmServiceConnection.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1086 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1056d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Redth/PushSharp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A software project. See architecture tab.

Developers.

See activity metrics.

Standard open source risks apply.

Check recent commits.

Check README for instructions.

• PushSharp.Core/ServiceBroker.cs — Central orchestration hub that manages notification queuing, routing to platform-specific connections, and error handling across all push services
• PushSharp.Core/IServiceConnection.cs — Abstract interface that all platform-specific connections implement; defines the contract for sending notifications and handling responses
• PushSharp.Core/INotification.cs — Base notification interface that all platform implementations extend; ensures type safety and consistent notification structure
• PushSharp.Apple/ApnsHttp2Connection.cs — HTTP/2 APNS implementation representing the modern push protocol for iOS; critical for Apple device delivery
• PushSharp.Google/GcmServiceConnection.cs — Google Cloud Messaging HTTP connection handler; manages batching, retries, and canonical ID updates for Android
• PushSharp.Core/ServiceBrokerConfiguration.cs — Configuration model for broker setup; defines how all platform connections are initialized and managed
• PushSharp.Core/PushHttpClient.cs — Shared HTTP client wrapper providing consistent request/response handling, retry logic, and timeout management across all platforms

Add support for a new push platform

1. Create a new folder PushSharp.NewPlatform with Configuration, Connection, Notification, and Exceptions classes (PushSharp.NewPlatform/NewPlatformConfiguration.cs)
2. Implement IServiceConnection interface in NewPlatformConnection.cs to define Send() async logic and connection initialization (PushSharp.NewPlatform/NewPlatformConnection.cs)
3. Create INotification-derived class NewPlatformNotification.cs with platform-specific payload properties (PushSharp.NewPlatform/NewPlatformNotification.cs)
4. Optionally implement IServiceConnectionFactory to handle connection pooling and lifecycle (PushSharp.NewPlatform/NewPlatformConnectionFactory.cs)
5. Add integration tests in PushSharp.Tests/NewPlatformTests.cs using TestServiceConnection pattern (PushSharp.Tests/NewPlatformTests.cs)
6. Update PushSharp.sln to include the new project and ensure it references PushSharp.Core (PushSharp.sln)

Extend a platform-specific connection with new notification features

1. Add new properties to the platform's Notification class (e.g., new APNS alert fields) (PushSharp.Apple/ApnsHttp2Notification.cs)
2. Update the Connection class's Send() method to serialize new properties into the platform API request (PushSharp.Apple/ApnsHttp2Connection.cs)
3. Parse and handle new response/error codes by extending the exception handling in Exceptions.cs (PushSharp.Apple/Exceptions.cs)
4. Add unit test case to validate the new notification fields are correctly transmitted (PushSharp.Tests/ApnsHttp2RealTests.cs)

Customize broker behavior (queuing, retry logic, error callbacks)

1. Create a ServiceBrokerConfiguration instance with custom OnServiceException and OnNotificationFailed callbacks (PushSharp.Core/ServiceBrokerConfiguration.cs)
2. In your app initialization, instantiate ServiceBroker with the config and add platform-specific configurations (PushSharp.Core/ServiceBroker.cs)
3. Call broker.QueueNotification() with your platform-specific notification instances to begin processing (PushSharp.Core/NotificationBlockingCollection.cs)
4. Monitor broker logs via PushSharp.Core/Log.cs or implement custom logging in the ServiceBroker callbacks (PushSharp.Core/Log.cs)

Handle platform-specific authentication/tokens (e.g., WNS OAuth, GCM server key)

1. Instantiate platform Configuration with required credentials (WnsConfiguration, GcmConfiguration, etc.) (PushSharp.Windows/WnsConfiguration.cs)
2. The Connection class constructor will call credential-refresh methods automatically during initialization (PushSharp.Windows/WnsConnection.cs)
3. For OAuth/token platforms, the TokenAccessManager or equivalent handles refresh logic and caching (PushSharp.Windows/WnsTokenAccessManager.cs)
4. Pass the platform Configuration to ServiceBroker.CreateConnection() to wire credentials into the pipeline (PushSharp.Core/ServiceBroker.cs)

• Async/await with Task-based APIs — Allows single-threaded scaling across millions of concurrent notifications without thread-pool exhaustion; enables responsive UI in consumer applications
• HttpClient for all platform APIs — Unified HTTP stack across Android (GCM), Windows (WNS), Amazon (ADM), and Blackberry; leverages connection pooling and modern TLS
• BlockingCollection for notification queue — Thread-safe producer-consumer pattern without explicit locking; integrates seamlessly with async Task-based processing
• Factory + interface-based dependency injection — Each platform (Apple, Google, Windows, etc.) is completely isolated; new platforms can be added without modifying core broker logic
• .NET Framework/Mono compatibility — Targets both

Standard debugging applies.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add async/await integration tests for ApnsHttp2Connection

The repo has migrated to async/await patterns (v3.0+ uses HttpClient and async), but there are no visible test files in the structure. ApnsHttp2Connection is a critical component handling Apple's modern HTTP/2 protocol. Integration tests validating connection pooling, certificate handling, and error resilience would catch regressions and provide examples for contributors.

• [ ] Create PushSharp.Apple.Tests/ApnsHttp2ConnectionTests.cs with async/await patterns
• [ ] Add tests for certificate validation and renewal scenarios
• [ ] Add tests for network failure handling and retry logic in ApnsHttp2ServiceConnection
• [ ] Ensure tests use the same HttpClient patterns as PushSharp.Core/PushHttpClient.cs

Implement unified exception handling and logging for GcmXmppConnection fallback scenario

The codebase has both GcmServiceConnection (HTTP) and GcmXmppConnection (XMPP) for Google Cloud Messaging, but there's no visible coordinated error handling or logging strategy between them. GcmConfiguration references both but it's unclear how fallback, retry, and exception propagation work. This causes maintenance burden when debugging production issues.

• [ ] Review PushSharp.Google/GcmConfiguration.cs and define explicit fallback logic between HTTP and XMPP
• [ ] Extend PushSharp.Core/Log.cs to include structured logging for service connection selection/fallback
• [ ] Add PushSharp.Google/GcmServiceConnectionFactory.cs to encapsulate connection selection logic
• [ ] Update GcmServiceConnection and GcmXmppConnection to use consistent exception wrapping from PushSharp.Google/Exceptions.cs

Add GitHub Actions CI workflow for cross-platform test matrix (Windows, Linux, macOS)

The repo has AppVeyor CI (Windows-only), but modern open-source practice requires cross-platform testing. PushSharp.Apple uses native certificates and networking that behave differently on macOS vs Linux. The .NET Core/Framework multi-targeting in .csproj files suggests cross-platform support is intended but not validated.

• [ ] Create .github/workflows/test.yml with matrix testing: [windows-latest, ubuntu-latest, macos-latest]
• [ ] Define separate certificate handling for local tests on each platform (mock certificates for Linux/Windows, real for macOS if available)
• [ ] Ensure GcmServiceConnection and BlackberryHttpClient tests run on all platforms
• [ ] Add workflow status badge to README.md with link to Actions tab

Check the issue tracker.

• High · Hardcoded Test Certificate in Repository — PushSharp.Tests/apns-com.pushsharp.sample.p12. The file 'PushSharp.Tests/apns-com.pushsharp.sample.p12' appears to be a hardcoded APNS certificate stored in the repository. This is a private key material that should never be committed to version control, even if it's a test certificate. It could be used for unauthorized push notifications and represents a credential exposure risk. Fix: Remove the certificate from the repository immediately. Use environment variables or secure credential management systems (e.g., Azure Key Vault, AWS Secrets Manager) to store certificates. Add *.p12, *.pfx, *.pem files to .gitignore. Consider rotating this certificate if it was ever used in production.
• High · Sample Settings File May Contain Credentials — PushSharp.Tests/settings.sample.json and PushSharp.Tests/packages.config. The file 'PushSharp.Tests/settings.sample.json' suggests there may be a settings file that contains sensitive configuration. If the actual settings.json file is committed (even accidentally), it could expose API keys, tokens, or other credentials for push notification services (APNS, GCM, ADM, etc.). Fix: Ensure settings.json is in .gitignore. Use only the .sample.json file for documentation. Store actual credentials in environment variables, secure configuration services, or local user secrets management (.NET User Secrets).
• Medium · Potential Insecure HTTP Communication — PushSharp.Apple/ApnsConnection.cs, PushSharp.Google/GcmServiceConnection.cs, PushSharp.Amazon/AdmConnection.cs, PushSharp.Blackberry/BlackberryHttpClient.cs. The codebase includes multiple push notification service integrations (APNS, GCM, ADM, Blackberry, etc.) that handle sensitive data. Without code review, there's risk of insecure HTTP fallback, missing certificate pinning, or improper TLS validation in connections to these services. Fix: Review all HTTP client implementations to ensure: TLS 1.2+ is enforced, certificate pinning is implemented where applicable, SSL/TLS validation is not disabled, and no HTTP fallback exists for credential transmission.
• Medium · Signing Key Present in Repository — PushSharp-Signing.snk. The file 'PushSharp-Signing.snk' is a strong name key file that should not be committed to public repositories. While it's used for assembly signing, exposure of this key could allow attackers to create malicious assemblies that appear to be from the legitimate publisher. Fix: Remove the .snk file from the repository. Implement secure key management practices: store signing keys in secure environments, use CI/CD pipelines with secure key injection, and add *.snk to .gitignore for future protection.
• Medium · Missing Input Validation on Notifications — PushSharp.Apple/ApnsNotification.cs, PushSharp.Google/GcmNotification.cs, PushSharp.Amazon/AdmNotification.cs, PushSharp.Blackberry/BlackberryNotification.cs. The notification classes (ApnsNotification.cs, GcmNotification.cs, etc.) handle user-supplied data that is transmitted to push services. Without proper input validation, there could be risks of injection attacks, XSS via notification content, or service abuse. Fix: Implement comprehensive input validation for all notification content fields. Sanitize and validate: message text, custom payloads, URLs, and badges. Use allowlisting for data formats. Implement size limits to prevent abuse.
• Medium · Exception Handling May Expose Sensitive Information — PushSharp.Core/Exceptions.cs, PushSharp.Apple/Exceptions.cs, PushSharp.Google/Exceptions.cs, PushSharp.Amazon/Exceptions.cs, and others. Exception classes exist across multiple modules (Exceptions.cs in multiple projects). If exceptions contain stack traces or sensitive details about credentials/tokens, error logging could expose security-sensitive information. Fix: Review exception handling to ensure: sensitive data (tokens, keys, device tokens) is never included in exception messages, stack traces are not logged in production, custom exception handling sanitizes error details before logging or returning to clients.
• Medium · undefined — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.