Hmmm. Speaking of Fediverse interoperability, platforms other than yours (Pandacap) typically arrange things so that https://pandacap.azurewebsites.net/ was the domain, and something like https://pandacap.azurewebsites.net/users/lizard-socks was the user, but Pandacap wants to use https://pandacap.azurewebsites.net/ for both. Combined with the fact that it doesn’t seem to support /.well-known/nodeinfo means that no other platform knows what software it’s running.

When your actor sends something out, it uses the id https://pandacap.azurewebsites.net/, but when something tries to look that up, it returns a “Person” with a subtly different id of https://pandacap.azurewebsites.net/ (no trailing slash). So there’s the potential to create the following:

1. https://pandacap.azurewebsites.net/ sends something out.
2. Instance hasn’t heard of that, so looks it up, and creates a new user in its database, with the returned ID (https://pandacap.azurewebsites.net/)
3. https://pandacap.azurewebsites.net/ sends else something out. Instance looks in it’s DB, finds nothing, so looks it up and tries to create it again. The best case is that it meets a DB uniqueness constraint, because the ID it gets back from that lookup does actually exist (so it can use that, but it was a long way around to find it). The worst case - when there’s no DB uniqueness constraint -is that a ‘new’ user is created every time.
4. Repeat step 3 for every new thing you send.

If every new platform treats the Fediverse as a wheel that needs to be re-invented, then the whole project is doomed.