I think there are a lot of disadvantages as you identified, so I’m kind of wondering what you see as the advantages or possible user flows that you want to make possible here. Based on what you’ve described, I don’t see any. To be clear, my perception of ActivityPub is mostly as a way to send notifications in the form of activities which can later be composed into “activity streams”. The side effects of the ActivityPub outbox allow for some publishing of web resources, as well as basic manipulation. Neither of these things serve the problem domain particularly well here.
I could see maybe having some integrations in the way of identity, but not so much in the way of communication, whether that be messaging or publishing. For example, you can indicate that you have a fediverse profile, or a website, or so on. But it’s unclear how much of what you do on-platform should be externalized onto a personal website.
Probably it would be helpful to think more about the expected interactions and boundaries of your service, and in what ways and in which contexts it makes sense to cross boundaries or enable cross-service interactions. I’d say don’t feel pressured into thinking that everything has to fit into the ActivityPub box.
To explore one of the examples you bring up of “liking another profile”, you could model this with a Like activity and the likes collection, but I suspect that this wouldn’t actually be very useful unless you wanted to track who “likes” you. In this sense, people can send a notification that they “like” you:
{
"@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"
}
And then this activity results in the following state for user 1:
{
"@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"]
}
}
And the following resulting state for user 2:
{
"@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
}
}
You could then do whatever logic you wanted against, say, making sure 2 users are mutually liked before indicating a match or allowing them to message each other. But again… is this kind of interaction flow “worth it” or desired in any way for the functionality of your application?