Feature Proposal: External RSVP Hook for "Going" Status

[ngerakines]

Summary

This proposal outlines a new feature that allows event organizers to intercept “Going” RSVP requests and redirect users to external ticketing or reservation systems, while maintaining seamless integration with Smoke Signal’s existing RSVP functionality.

Problem Statement

Currently, when users RSVP to events on Smoke Signal, the process is entirely contained within the platform. However, many events require external ticketing systems, payment processing, or additional registration steps that cannot be handled directly within Smoke Signal. Event organizers need a way to redirect users to these external systems while still maintaining the social aspects and attendance tracking in the ATmosphere.

Proposed Solution

Core Functionality

Introduce an optional RSVP Hook feature that allows event organizers to configure a redirect URL for “Going” RSVPs. When enabled:

1. “Interested” RSVPs continue to work exactly as they do today
2. “Going” RSVPs trigger a redirect to the configured external URL instead of immediately creating the RSVP record
3. The external system handles ticketing/registration and can redirect back to Smoke Signal
4. Upon return, the RSVP can be completed normally or pre-populated by the external system with query string parameters

User Experience Flow

For “Interested” RSVPs (No Change)

1. User clicks “Interested” on event page
2. RSVP is created immediately
3. User sees confirmation

For “Going” RSVPs (New Behavior)

1. User clicks “Going” on event page
2. If no hook configured: Normal RSVP creation (existing behavior)
3. If hook configured: User is redirected to external URL with context parameters
4. External system handles ticket purchase/registration
5. External system redirects back to Smoke Signal (optionally with completion data)
6. User completes RSVP process on Smoke Signal

Technical Implementation

Event Configuration

Add new optional fields to event configuration:

• rsvp_hook_url: The external URL to redirect to
• rsvp_hook_enabled: Boolean to enable/disable the feature
• rsvp_hook_auto_create: Boolean indicating if external system will create the RSVP

URL Parameters

When redirecting to the external system, include context:

https://external-system.com/tickets?aturi={event_aturi}&cid={event_cid}&identity={did}&return_url={encoded_return_url}

Return URL Handling

The return URL should support:

• Automatic RSVP creation if the external system provides completion confirmation
• Pre-filled RSVP form for manual completion
• Error handling for failed external processes

Direct RSVP Form Bypass

The hook should only apply to the main event page RSVP buttons. Direct access to RSVP forms (via direct URLs) should bypass the hook, allowing:

• External systems to complete RSVPs programmatically
• Admin/organizer override capabilities
• Fallback functionality if external systems fail

Benefits

For Event Organizers

• Seamless integration with existing ticketing platforms
• Maintained social features and attendance tracking
• Flexibility to handle complex registration requirements
• Revenue generation through external ticket sales

For Attendees

• Single-click access to ticket purchasing
• Familiar Smoke Signal interface for event discovery
• Social proof and community features remain intact
• Clear indication of attendance status

For Platform

• Increased event organizer adoption
• Integration opportunities with ticketing partners
• Maintained user engagement within Smoke Signal ecosystem

Implementation Considerations

Backwards Compatibility

• Feature is entirely opt-in for event organizers
• Existing events continue to work unchanged
• No breaking changes to current RSVP functionality

Security

• Validate return URLs to prevent redirect attacks
• Implement CSRF protection for hook configuration
• Sanitize external system responses

Error Handling

• Graceful fallback if external system is unavailable
• Clear error messages for users
• Logging for debugging integration issues

Mobile Experience

• Ensure redirect flow works smoothly on mobile devices
• Consider deep-linking capabilities for mobile apps

Next Steps

1. Community Feedback: Gather input from event organizers and users
2. Technical Specification: Detailed API and implementation docs
3. Prototype Development: Build minimal viable version for testing
4. Partner Integration: Work with popular ticketing platforms for seamless experience
5. Documentation: User guides and developer documentation

Questions for Discussion

1. Should there be any limitations on external URLs for security?
2. How should we handle situations where users don’t return from external systems?
3. What additional context should be passed to external systems?
4. Should we support webhook notifications from external systems?
5. How should this feature be presented in the event creation interface?

---

This proposal is open for community discussion and feedback. Please share your thoughts, concerns, and suggestions.

[ngerakines]

After thinking about it more, I think this could be expanded to a more general RSVP intention service. This approach provides better security, more granular control, and cleaner integration with the existing AT Protocol infrastructure.

Proposed XRPC Method: tools.smokesignal.intention.register

Instead of a simple redirect hook, introduce a new XRPC procedure that allows event organizers to register an intention service endpoint that Smoke Signal will invoke during the RSVP process.

Implementation Overview

Event Creation Changes

When creating an event, organizers can:

• Check a box to enable “RSVP Intention Service”
• This links their event to their pre-configured XRPC intention endpoint
• No additional configuration needed per-event (endpoint is tied to organizer identity)

RSVP Process Flow

Current Flow (No Intention Service)

1. User submits RSVP form
2. Smoke Signal creates RSVP record immediately
3. User sees confirmation

New Flow (With Intention Service)

1. User submits RSVP form
2. Smoke Signal makes XRPC call to registered intention endpoint
3. XRPC call includes:
   • Event AT-URI and CID
   • User DID (identity)
   • RSVP status ("going", "interested", "notgoing")
4. Intention service responds with one of three options:
   • "allow": Proceed with normal RSVP creation
   • "deny": Display error message to user
   • {redirect_url: "https://..."}: Initiate secure redirect flow

Secure Redirect Flow

When the intention service returns a redirect URL:

Step 1: JWT Generation

Smoke Signal creates a JWT containing:

{
  "event_uri": "at://did:plc:example/community.lexicon.calendar.event/abc123",
  "event_cid": "bafyrei...",
  "rsvp_status": "going",
  "user_did": "did:plc:user123",
  "exp": 1640995200,  // 6 hours from now
  "iss": "smokesignal.events",
  "aud": "smokesignal.events"
}

Step 2: Redirect URI Construction

Smoke Signal crafts a return URL:

https://smokesignal.events/rsvp/complete?token={jwt_token}

Step 3: User Redirect

Browser redirects to intention service URL with return parameter:

https://external-system.com/tickets?redirect_uri={encoded_return_url}

Step 4: Return Processing

When user returns to Smoke Signal:

1. Validate JWT signature and expiration
2. Extract RSVP details from JWT claims
3. Create RSVP record using validated data
4. Display confirmation to user

Technical Advantages

Security Benefits

• JWT-based state management: Prevents tampering with RSVP data during external flow
• Time-limited tokens: 6-hour expiration prevents replay attacks
• Cryptographic signatures: Ensures data integrity
• No URL parameters exposure: Sensitive data encrypted in JWT

Flexibility Benefits

• Granular control: Services can allow/deny without external redirects
• Status-agnostic: Works for any RSVP status, not just “going”
• Conditional logic: Intention services can implement complex business rules
• Error handling: Clean deny responses with custom messaging

Integration Benefits

• AT Protocol native: Uses existing XRPC infrastructure
• Consistent patterns: Follows established webhook-style patterns
• Identity-based: Leverages DID system for user identification
• Backwards compatible: Existing events continue working unchanged

Example XRPC Intention Service Response Patterns

Allow RSVP

{
  "action": "allow"
}

Deny RSVP

{
  "action": "deny",
  "message": "Event is at capacity"
}

Redirect for Processing

{
  "action": "redirect",
  "redirect_url": "https://ticketing-system.com/event/12345",
  "message": "Complete ticket purchase to confirm attendance"
}

Benefits Over Simple Redirect Approach

1. Better Security: JWT prevents state tampering vs URL parameters
2. More Flexible: Can handle allow/deny without redirects
3. Protocol Consistent: Uses established XRPC patterns
4. Easier Testing: XRPC calls can be tested independently
5. Better Error Handling: Structured responses vs redirect failures
6. Identity Integration: Native DID support vs parameter passing

Implementation Considerations

XRPC Endpoint Registration

• Event organizers register intention endpoints in their account settings
• Endpoints must implement the tools.smokesignal.intention.register schema
• Support for endpoint validation and testing tools

Rate Limiting

• Implement reasonable rate limits on intention service calls
• Cache “allow” responses for short periods to reduce external calls
• Graceful fallback if intention service is unavailable

Monitoring and Debugging

• Log XRPC call failures for organizer debugging
• Provide intention service response analytics
• Support for testing endpoints before going live

Migration Path

This approach can be implemented alongside the simpler redirect hook method:

1. Phase 1: Implement basic redirect hooks (original proposal)
2. Phase 2: Introduce XRPC intention services
3. Phase 3: Migrate power users to XRPC approach
4. Phase 4: Deprecate simple redirects (optional)

Questions for Further Discussion

1. Should intention services be able to modify RSVP data (e.g., add metadata)?
2. How should we handle intention service timeouts or failures?
3. Should there be different intention endpoints for different RSVP statuses?
4. What additional claims should be included in the JWT?
5. Should intention services be able to return custom success messages?

---

This XRPC-based approach provides a more robust foundation for external RSVP processing while maintaining the flexibility and ease of use that event organizers need. I believe this represents a significant improvement over the simpler redirect approach while still solving the core use case.

Thoughts?

[boris]

I think this is a really well thought out pattern for weaving together services.

We know we can do this with Tito to start, and lots of other systems with solid APIs should be doable this way as well.

JWTs are directionally where capabilities and more auth between systems are heading.