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.

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.

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

Not saying this won’t have any negative effects on people, however I think it’s a little premature to guess at what it will be like. About 3/4 of the article is commenting what it will do to men when we find out only at the end women are the majority of users.

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

Why not? Copyright is a monopoly. Generally society benefits from having it as weak as possible.

Worth considering that this is already the law in the EU. Specifically, the Directive (EU) 2019/790 of the European Parliament and of the Council of 17 April 2019 on copyright and related rights in the Digital Single Market has exceptions for text and data mining.

Article 3 has a very broad exception for scientific research: “Member States shall provide for an exception to the rights provided for in Article 5(a) and Article 7(1) of Directive 96/9/EC, Article 2 of Directive 2001/29/EC, and Article 15(1) of this Directive for reproductions and extractions made by research organisations and cultural heritage institutions in order to carry out, for the purposes of scientific research, text and data mining of works or other subject matter to which they have lawful access.” There is no opt-out clause to this.

Article 4 has a narrower exception for text and data mining in general: “Member States shall provide for an exception or limitation to the rights provided for in Article 5(a) and Article 7(1) of Directive 96/9/EC, Article 2 of Directive 2001/29/EC, Article 4(1)(a) and (b) of Directive 2009/24/EC and Article 15(1) of this Directive for reproductions and extractions of lawfully accessible works and other subject matter for the purposes of text and data mining.” This one’s narrower because it also provides that, “The exception or limitation provided for in paragraph 1 shall apply on condition that the use of works and other subject matter referred to in that paragraph has not been expressly reserved by their rightholders in an appropriate manner, such as machine-readable means in the case of content made publicly available online.”

So, effectively, this means scientific research can data mine freely without rights’ holders being able to opt out, and other uses for data mining such as commercial applications can data mine provided there has not been an opt out through machine-readable means.

Well, in a way that’s what we’re doing now, and by and large it works but obviously there’s some leakage, which is impossible to bring down to zero but which makes sense working on improving.

The other side of the coin is that the price of this moderation model is subjecting a lot more people to a lot more horrible shit, and I unfortunately don’t know any way around that.

Perhaps the manual reporting tool is enough? Then that content can be forwarded to the central ms service. I wonder if that API can report back to say whether it is positive.

The problem with a lot of this tooling is you need some sort of accreditation to use it, because it somewhat relies on security through obscurity. As far as I know you can’t just hit MS’s servers and ask “is this CSAM?” If something like that were possible it might work.

Can you elaborate on the hash problem?

Sure. When you have an image, you can do lots of things to it that change it in some way: change the compression, the format, crop it, apply a filter… This all changes the file and so it changes the hash. The perceptual hash system works on the basis of some computer vision stuff and the idea is that it will try to generate the same hash for pictures that are substantially the same. But this tech is imperfect and probably will have changes. So if there’s a change in the way the hash gets calculated, it wouldn’t be enough with keeping hashes, you’d have to keep the original file to recalculate, which is storing CSAM, which is ordinarily not allowed and for good reason.

For a hint on how bad these hashes can get, they are reversible, vulnerable to pre-image attacks, and so on.

Some of this is probably inevitable in this type of systems. You don’t want to make it easy for someone to hit the servers with a large number of hashes, and then use IPFS or BitTorrent DHT to retrieve positives (you’d be helping people getting CSAM). The problem is hard.

Personally I was thinking of generating a federated set based on user reporting. Perhaps enhanced by checking with the central service as mentioned above. This db can then be synced with trusted instances.

Something like that could work, maybe obscuring some of the hash content (random parts of it) so that it doesn’t become a way to actually find the stuff.

Whatever decisions are made have to be well thought through so as not to make the problem worse.

Clearly this particular suit by this particular person is iffy. However, I don’t think this framing is very good: the fact Wikimedia is headquartered elsewhere shouldn’t make it immune from being sued where an affected party lives.

Also, this part of the article seems a bit contradictory:

Just because someone doesn’t like what’s written about them doesn’t give them the right to unmask contributors. And if the plaintiff still believes he’s been wronged by these contributors, he can definitely sue them personally for libel (or whatever). What he has no right to demand is that a third party unmask users simply because it’s the easiest target to hit.

Ok, but how does he sue them personally without knowing who they are? It’s fine to say this shouldn’t be regarded as libel (I agree, it’s a factual point, should be covered by exceptio veritatis or whatever) but I think it’s a bit dishonest to say you can’t hit Wikimedia, go after the individual users; but also, Wikimedia shouldn’t be forced to reveal them.

Much better if the court would consider this information as being accurate and in the public interest.

Of course the GDPR cuts two ways here, because political information is an especially protected category, with certain exceptions (notorious information). So I’m not sure how the information on this person’s affiliation to the far right was obtained and so on.

IMO the hardest part is the legal side, and in fact I’m not very clear how MS skirted that issue other than through US lax enforcement on corporations. In order to have a db like this one must store stuff that is, ordinarily, illegal to store. Because of the use of imperfect, so-called perceptual hashes, and in case of algorithm updates, I don’t think one can get away with simply storing the hash of the file. Some kind of computer vision/AI-ish solution might work out, but I wouldn’t want to be the person compiling that training set…

I generally agree, though I could be convinced of recurring payment in the case of high speed APIs that need a lot of updates to keep working. Chasing an API can be a lot of work.

Of course, a solution to that is having an up-front payment and letting people update as they wish–if there’s new value in the new releases presumably they will.

Welcome back!

There were points at which Firefox was difficult to stick with, especially after the extension apocalypse, but I think it’s evolving pretty well at this point.