Building an online dating platform presents unique challenges, especially when considering the underlying infrastructure. The concept of a “Dating Server” emerges as a potential solution, but its advantages and disadvantages warrant careful examination. This article delves into the complexities of dating servers, exploring their potential user flows and whether they truly offer a beneficial approach for fostering online connections.
One perspective questions the very essence of dating servers, particularly when viewed through the lens of protocols like ActivityPub. ActivityPub, often perceived as a mechanism for activity streams and notifications, might not seamlessly translate to the intricate demands of a dating environment. While ActivityPub’s outbox could facilitate web resource publishing and basic data manipulation, these functionalities might not directly address the core problem domain of a dating service.
Identity integration appears to be a more readily applicable aspect of ActivityPub in this context. Users could potentially link their dating server profiles to broader fediverse identities or personal websites. However, the extent to which on-platform activity should be externalized remains an open question. Defining clear boundaries and expected interactions within the service is crucial before attempting to force-fit everything into the ActivityPub framework.
Consider the simple act of “liking” a profile. While ActivityPub can model this interaction using a Like activity and associated collections, the practical utility of such an approach is debatable. Unless the platform aims to meticulously track “likes” for analytical purposes, the added complexity might outweigh the benefits. The example below illustrates how a “like” interaction could be structured using ActivityPub:
{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://dating.example/users/1/activities/1" "actor": "https;//dating.example/users/1", "type": "Like", "object": "https;//dating.example/users/2", "to": "https;//dating.example/users/2" }This activity could then lead to state changes for both users. User 1, who initiated the “like,” would have user 2 added to their “liked” collection:
{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https;//dating.example/users/1", "type": "Person", "name": "Alex", "inbox": "https://dating.example/users/1/inbox", "likes": { "id": "https://dating.example/users/1/likes_of_me", "type": "Collection", "totalItems": 0 }, "liked": { "id": "https://dating.example/users/1/who_i_like", "type": "Collection", "totalItems": 1, "items": ["https;//dating.example/users/2"] } }Conversely, User 2 would have User 1’s activity recorded in their “likes_of_me” collection:
{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https;//dating.example/users/2", "type": "Person", "name": "Blake", "inbox": "https://dating.example/users/2/inbox", "likes": { "id": "https://dating.example/users/2/likes_of_me", "type": "Collection", "totalItems": 1, "items": [ "https://dating.example/users/1/activities/1" ] }, "liked": { "id": "https://dating.example/users/1/who_i_like", "type": "Collection", "totalItems": 0 } }This structure could facilitate logic for matching users based on mutual “likes” or enabling messaging only after a mutual connection is established. However, the fundamental question remains: does this level of complexity and interaction flow genuinely enhance the user experience and functionality of a dating application? The answer hinges on a deep understanding of desired user interactions and whether the intricacies of a dating server, potentially leveraging protocols like ActivityPub, align with those needs or introduce unnecessary overhead.
