Definitely, AP is not magic. But if even within one protocol round-tripping and full-fidelity is impossible or very difficult, that makes it only harder and less likely through a bridge.

IMO bridging or translation isn’t federation per se. Also it seems unlikely that protocols would converge to that extent. In fact AP implementations are already different enough that even within the same protocol it’s hard to represent all the different activities instances can present.

I wouldn’t really count Mastodon/Bluesky bridging as federation. They’re incompatible protocols that were never intended to work together (arguably Bluesky was explicitly designed to avoid using AP).

For me the weirdest part of the interview is where he says he doesn’t want to follow anyone, that he wants the algorithm to just pick up on his interests. It’s so diametrically opposed to how I want to intentionally use social networks and how the fedi tends to work that it’s sometimes hard to remember there are people who take that view.

Ah, that does seem like it will solve the problem. Thanks!

Not sure I understand. What I’m trying to do is something like this:

• Poll a stream which takes fedi events. Read player commands.
• If an event comes from a known player, check which match they are into.
• With that info, get their opponents/coplayers etc and perform the change of state in the game (send replies, next turn, etc).

So what I have as a key is a player name (AP username) and from that I need to find which match they’re in.

There’s nothing semantically useful about a match ID.

Thanks, the RC is a possible approach. It seems to violate DRY a bit but maybe there’s no way around it.

The reason I had the players outside the match is that I need them there anyway, because when I get a player action I need to check in which match they are, who are their opponent(s) and so on. So even if they’re in, they’ll have to be out too as there are concurrent matches and the player actions come all through the same network stream.

I can think of alternatives. For example, the server could keep the user’s private key, encrypted with a passphrase that the user must have. So key loss wouldn’t be an issue. (Yes, passphrase loss might, but there are lots of ways to keep those safely already, compared to key material which is difficult to handle.)

Security and performance are hard to measure but it’s at least questionable that they’re behind in either.

AI has many good uses, for example the local translation capability that allows for privacy-preserving translations of websites is AI and already in Firefox, and makes it possible to translate in environments that do not allow sending data out for security reasons.

So, not super sure what this is or how this works. Is the idea that you run the cgi, it sets up static files, and it responds to AP requests like follows, mentions, boosts and such? I realise lots of people don’t like long docs but I didn’t really understand the use case very well.

On my instance, the following control measures apply:

• Only public posts are visible through the web interface.
• Only public posts appear on RSS.
• Following requires approval.
• Authorised fetch is required.

So I think I have reason to feel fairly strongly that follower only posts are not public, and even unlisted posts are reasonably restricted.

Possibly yes. I’ll check if the results are equivalent.

Apparently the problem is due to an incompatibility between the use of certain libraries (winapi and windows-sys) which use different versions of COM. At least so I deduce from the documentation I’ve read.

There’s a workaaround:

On Cargo.toml, use.

[build-dependencies]
embed-manifest = "1.3.1"

And on the root of the project (not the src dir) create a build.rs file with the following content:

use embed_manifest::{embed_manifest, new_manifest};

fn main() {
    if std::env::var_os("CARGO_CFG_WINDOWS").is_some() {
        embed_manifest(new_manifest("Contoso.Sample")).expect("unable to embed manifest file");
    }
    println!("cargo:rerun-if-changed=build.rs");
}

This embeds a manifest together with the executable, solving the issue.

Same erro by using this approach.

Tokio works fine, by itself. windows-native-gui works fine, by itself. It is the combination that causes this issue.

The way I look at this is I have a reasonable understanding of rust. I’m not an expert but I can more or less do whatever computation I need to do, use crates, and so on. But with async it’s like learning another language. Somewhat of an exaggeration, but it’s not just what code you need to write, but also being able to read the error messages from the compiler, understanding the patterns and so on. So yes, it’s probably fine, but it does take work.

There is literally no instance in which expanding the scope of copyright law is a good thing. Never.

So probably the tokio mpsc channel, right? Why is it not possible tu use normal sync channels? I’ve read about it but I don’t understand the reason.

Also I’m thinking of spawning a thread to do this part, or should it run on the tokio main function?

I’ve had just this case. Wanted to use a particular crate that uses async and it’s forcing me to do lots of async things I’m unfamiliar with. I resent it a little, especially for a program that I’m fairly sure will not require concurrency of this sort.

At the same time, maybe I’ll get used to async rust if I use it enough. But so far I’m not having a lot of fun with it.

As far as I can tell, this is incorrect. If there’s a post on instance A, a reply from instance B, and someone on instance C follows the OP on A but not the RP on B, they will only see the OP without the reply.

Source: I very often notice this because I run a single-user instance, and when I open a thread it’s incomplete, lacking posts from instances that I have not suspended.

The biggest issues for me are:

1. No centralisation means there’s no canonical single source of truth.
2. Account migration.
3. Implementation compatibility.

No single source of truth leads to the weird effect that if you check a post on your instance, it will have different replies from those on a different instance. Only the original instance where it got posted will have a complete reply set–and only if there are no suspensions involved. Some of this is fixable in principle, but there are technical obstacles.

Account migration is possible, but migration of posts and follows is non-trivial, Also migration between different implementations is usually not possible. Would be nice if people could keep a distinction between their instance, and their identity, so that the identity could refer to their own domain, for example.

Last, the issue with implementation compatibility. Ideally it should be possible to use the same account to access different services, and to some extent it works (mastodon can post replies to lemmy or upvote, but not downvote, for example).