• 0 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle

  • AFAIK, the only practical thing in the way of having a separate server that just hosts identity accounts for all types of fediverse content (while the content itself is hosted on other servers) is that your host server is responsible for presenting the interface through which you view the rest of the fediverse, and the interfaces are specialized for a particular content type. You could have a server running a variety of fediverse software (mastodon, lemmy, etc.) which automatically generates similar accounts for each user on each service, so users could sign up once and then switch interfaces; but I think the rest of the fediverse would still treat them as separate identities.




  • Rather than starting from scratch, would it make more sense to make an ActivityPub plugin for the open-source MediaWiki software Wikipedia runs on? MediaWiki already has some “interwiki” functionality that such a plugin could expand on, and you’d have the advantage of being able to fork content from WP and other MW projects without having to re-format it. Plus you’d be able to leverage other MW plugins—Semantic MediaWiki in particular could add a lot of useful functionality to federated wikis, like articles that could query and aggregate information from other federated articles rather than just linking to the text.




  • If an account is upvoted because it’s posting high-quality content, we’d expect those votes to come from a variety of accounts that don’t otherwise have a tendency to vote for the same things.

    Suppose you do regression analysis on voting patterns to identify the unknown parameters determining how accounts vote. These will mostly correlate with things like interests, political views, geography, etc.—and with bot groups—but the biggest parameter affecting votes will presumably correlate with a consensus view of the general quality of the content.

    But accounts won’t get penalized if their votes can be predicted by this parameter: precisely because it’s the most common parameter, it can be ignored when identifying voting blocs.


  • There are legitimate reasons for creating a “low-usage” server to host your personal account, so you have full control over federating etc.

    If we start assuming all small instances are spam by default, we’ll end up like email now—where it’s practically impossible for small sites to run their own mail servers without getting a corporate stamp of approval from Google.


  • Here’s an idea: adjust the weights of votes by how predictable they are.

    If account A always upvotes account B, those upvotes don’t count as much—not just because A is potentially a bot, but because A’s upvotes don’t tell us anything new.

    If account C upvotes a post by account B, but there was no a priori reason to expect it to based on C’s past history, that upvote is more significant.

    This could take into account not just the direct interactions between two accounts, but how other accounts interact with each of them, whether they’re part of larger groups that tend to vote similarly, etc.