Mostly just used for moderation.
Main account is https://piefed.social/u/andrew_s

  • 30 Posts
  • 48 Comments
Joined 3 years ago
cake
Cake day: July 24th, 2023

help-circle
  • The API provides it, which means that many of the clients will also have a way of displaying them.

    Your instance provides an alternative UI via the ‘Photon’ client at https://p.feddit.org/ - you can use this on desktop to view your profile and select the ‘Upvoted’ view.

    The command-line equivalent would be
    curl --header 'authorization: Bearer LOGIN_TOKEN' 'https://feddit.org/api/v3/post/list?liked_only=true&page=1&limit=50' | jq .posts[].post.id | xargs -I {} echo "https://feddit.org/post/%7B%7D"
    but it’s nowhere near as convenient as getting a client to do it for you.

    The other site mentioned - https://lemvotes.org/ - doesn’t use the API and is a bit controversial: it tends to be used to see who else voted for a post, and isn’t guaranteed to be a reliable way to show what posts you personally voted for.










  • 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.