Thanks for the correction. I sometimes get those two mixed up in my memory, and it’s a really stupid problem that I need to fix.

You interjected and then tried to educate to me what my comments are about.

My original comment was a comment. The only reason it continued is because neither of us seem to be content with letting other people be confidently wrong.

Any brand account on a regular Mastodon instance would be the very same.

Now imagine that it comes from a non-brand account that you follow. You have an ad. On your Mastodon instance. Federated by Threads.

Mastodon doesn’t have an algorithmic timeline, so that would lead to absolutely nothing.

Let’s address the elephant in the room: the parts of Mastodon that I previously mentioned but were deemed to be out-of-place goalposts. Here, I even did the research:

https://github.com/mastodon/mastodon/blob/27965ce5edff20db2de1dd233c88f8393bb0da0b/app/models/trends/statuses.rb#L103

Trends use both the boosts and favorites count for calculating scores.

Although it doesn’t solve the issue of ads being propagated in the first place, I will admit that having the option for manual admin approval is a nice mitigation, though.

Relevant to the comment I’ve initially replied to.

After coming back and fully re-reading this thread again, I’ll give you that.

What copyright? Threads users gave it away when they signed up.

Nope.

Let me rephrase that without hyperbole: you gave them the ability to do what they want to do with your copyright.

https://edit.tosdr.org/services/219

“Very broad copyright license on your content.” “You maintain ownership of your content.”

No, I made several good arguments, you just moved goalposts and declared they don’t matter.

Let’s see…

Still no reason to defederate, huh?

You:
No, it’s not. Ads can’t federate. Threads has no control over my Mastodon feed and Lemmy can’t interact with Threads at all. Following Threads accounts from Mastodon is effectively an ad blocker.

Neither of us:
How do you know that Threads won’t inject ads as posts?

You:
Ads in Instagram are posts from accounts you don’t follow. Threads can’t make you follow promotion accounts you don’t want to follow.

Me: Depending on where they want to sit in the scumbag chart, there’s no technical barrier stopping them from selecting threads-hosted accounts with high metrics and injecting advertisement posts under their handles.

You are correct that ads on Instagram are posts.

You are also correct that the federation protocol can’t force you to follow users, and that ads won’t show up in your feed unless you are subscribed to the user. You did not answer the user’s question asking if you knew that “threads won’t inject ads as posts.”

You are not correct in that “ads can’t federate”. I pointed out that the federation protocol doesn’t prevent an instance owner (Threads) from sending out ads as posts under any account hosted under their domain.

That was a technical argument for how they could actually federate ads if they wanted to. The discussion should have ended there while it was about the extent of what they could do to overreach in the fediverse. You were the one who decided to move the goalposts by bringing copyright and advertising standards into it.

My follow-up comments with shoddily-explained examples of how Meta could try weaseling out of consequences by abusing terms of services and pedantically following the letter of the law over of the spirit evidently isn’t a successful way to communicate a point. All of that crap was to say that Meta does not respect the law when money is to be made. They have been fined for prioritizing ad money over data collection laws and even antitrust laws. They even got away with blaming their advertising platform approving and nearly publishing COVID-19 misinformation ads on automation. If they were to consider the potential profits to outweigh the risks from getting fined, they would do it and try to lawyer their way out of being held accountable.

If the direction of our discussion were to continue, you’re going to disagree with me, I’m going to disagree with you, and we’ll both come out of this wasting more time. I would prefer that neither of us waste more time on this, though.

As long as you are, I’m more than happy to call this a misunderstanding over whether Theads “can” or “will” use ActivityPub to distribute ads turned petty disagreement and move on. Agreed?

The topic is ads being placed in the fediverse in a way only defederation could block. Even if Meta silently making posts in the name of my favorite organic orange juice advertising Coca-Cola was legal (it’s not), it would be easily solved by simply not following any Threads accounts.

Let’s go with your idea of what the topic is for a second: have you considered how advertisement posts could appear in search results, hashtags, or the explore section? Or what if they decide to screw with the normal process and artificially inflate the number of boosts and favorites for advertisement posts? Okay, the solution is to simply have your instance users refrain from following any Threads accounts so the posts don’t show up anywhere—which is effectively defederation.

Also, Lemmy cannot interact with Threads anyway, so Lemmy servers defederating from Threads is completely pointless.

Irrelevant to what I’m saying.

That would violate copyright, consumer protection, competition laws, and whatnot, at least in the USA and the EU.

Copyright to what? A person’s name? A small string of characters that is a “handle”? None of that is copyrightable.

That would violate copyright, consumer protection, competition laws, and whatnot, at least in the USA and the EU.

Doot Doot @SomePerson@example — 4h

Looking for gifts in time for the holiday season? Head on down to Best Buy to pick up some amazing deals on Black Friday!

– This is an advertisement shown to you by Meta. Click here for more info. –

That would violate copyright, vonsumer protection, competition laws, and whatnot, at least in the USA and the EU.

As I previously mentioned, corporate accounts can be excluded to remove running afoul of competition laws.

Mastodon users (!!) must be explicitly aware that a post is an ad, not the brands ticking off an EULA on Threads.

As with my example toot above, that took all of 15 words. They don’t need to be deceptive about what is or isn’t an advertisement to push that shit through the ActivityPub protocol.

Threads cannot legally impersonate one account on Threads to advertise another account.

Your whole argument is predicated on the idea that a (personal) account on Threads is either owned by its creator, or is associated with a trademark. Furthermore, there are a number of different approaches they could take to argue that the ActivityPub support provides access to a feed of content, and not an individual identity.

In any case, you’re repeatedly glossing over the fact that my original point was to say there isn’t a way to prevent it AT THE PROTOCOL LEVEL.

If they’re still allowed on the platform to speak their mind amongst their ilk, doesn’t that just create an echo chamber of idiots? Assuming they stay instead of leaving after their fe-fes get hurt, of course.

I would say quitting twitter to join bluesky is more like quitting menthols PCP to smoke regular cigarettes

Fixed that for you.

For those who are unfamiliar,

PCP may cause hallucinations, distorted perceptions of sounds, and violent behavior.

From my previous comment:

selecting threads-hosted accounts

ActivityPub literally will not let them impersonate accounts from other instances. That much should be obvious. The topic is about them impersonating their own users and using that to push ads through federation.

For some reason, my brain inserted a “like” before “in C#”, and answered the question of “can’t you use explicit interfaces like in C#.”

identity fraud

I’m sure they could find some way to have the terms of service agreement include a paragraph on how a handle is the property of Meta and not a user identity.

My favorite fair trade drink endorsing Coca-Cola.

Business accounts can be exempted from injected advertising.

Without the ads being clearly separated as required by many jurisdictions.

Post the ad as an image attachment and put the advertising disclaimer within the image? There’s a lot of ways they can make an ad disguised as a post, and not all of them are as easy to filter out as a quick text search.

Not targeted advertising in any way.

If @OutdoorsyOdin posts content about hiking and mountain climbing, you can make a reasonable guess that the subscribers are going to be interested in that kind of activity. It’s not targeted to a specific user, but it’s good enough to serve ads targeted at specific lifestyles or hobbies.

Users could just opt not to follow Threads accounts.

Exactly.

Anyways, this whole thing is to show that they could try to enshittify their fediverse integration if they really wanted to. There’s no technological barrier preventing them from sending ads through ActivityPub.

What are some common situations where using an object is a good solution?

It depends on what you mean by “object”

• Some kind of structured data?
• Some named type which fulfills an interface?

When you have some kind of structured data, having a class to represent it is fine. If you’re able to give it type annotations, that’s much better than passing around random dictionaries.

When you need polymorphism and have an interface where some method on an object needs to exist (e.g. car.honk()), that’s also fine as long as you avoid creating subclasses and using inheritance. If you need some car that can honk like a truck and drive like a racecar, use composition.

What I would consider a good use of classes (more specifically, nominal types) is dependent types. The idea is that you use the type system to enforce invariants for data.

For example, suppose you have a string for a user email. It might be a valid email string, or it might be garbage like “z#%@(”=))??". You have a function for updating the user email in a database, and it requires the email string to be valid.

One approach is to validate the email string after receiving it from the user. That works, but what if your coworker creates a new form and forgets to validate the email string there? Bad data gets passed downstream to functions that expect well-formed data.

Another approach is to validate the email string at the top of every function that expects well-formed data. That also works, but now you’re validating the same string multiple times and pasting validate_email(email) everywhere.

With a dependent type, you have a ValidatedEmail type and a constructor for it. The constructor will return an instance of the ValidatedEmail if and only if the email string is valid. Any function that expects a valid email will only accept a ValidatedEmail, and not a string. If your coworker creates a new form and forgets to validate the email, the type system will complain about a string being passed instead of a ValidatedEmail. You also shift the responsibility of validating the email to wherever there is a boundary between validated and unvalidated data, avoiding unnecessary validation since you know a ValidatedEmail is already valid.

It’s an extremely useful paradigm for avoiding logic errors, but it’s unfortunately not as common as it should be.

Edit: I misread your comment as “like in C#” and wrote this as an answer to the non-existent question of “can’t you use explicit interfaces like in C#”

I haven’t kept up with recent Java developments, but with Go, you’re out of luck. Interface implementations are completely implicit. You don’t even have an implements keyword.

Edit: For Java, a cursory search suggests that they haven’t yet added explicit interfaces: https://stackoverflow.com/questions/19111090/does-java-support-explicit-interface-implementation-like-c

just one more oop bro I swear

Didn’t understand my criticisms of Go and Java’s interfaces, or do you just enjoy LARPing as a senior programmer while living in a small world where the term “interface” strictly means object-oriented programming and not the broader idea of being a specification describing how systems can interact with each other?

That’s entirely the fault of applications (or more likely their libraries) using internal APIs or JNI. As long as it isn’t doing anything screwy with reflection and class loading or using the sun.* packages that aren’t part of the language specification, Java bytecode compiled for ancient Java versions will still work on modern versions.

What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react.

If anon’s program was designed to work as a client for some external server or if Java had absolutely no GUI frameworks, that would be fine. But if anon’s goal was to create a simple desktop application, doing this would be the programming equivalent of a Rube Goldberg machine.

With that approach, you also need to be really careful about how you do it. Fuck that part up and you can end up with the locally-hosted REST server listening on the device’s public network interface or vulnerable to CSRF from a web page opened in the user’s browser.

I strongly prefer how interfaces are handled

It’s better than Java, but they still chose to walk headfirst into the same trap that bites Java developers in the ass: associating interface implementations with the struct/class rather than the interface itself.

When you have two interfaces that each require you to implement a function with the same name but a different signature, you’re in for a bad time featuring an abomination of wrapper types.

Edit: Clarity.

Depending on where they want to sit in the scumbag chart, there’s no technical barrier stopping them from selecting threads-hosted accounts with high metrics and injecting advertisement posts under their handles.

TypeScript isn’t terrible. It’s extra work to set up, but it makes JavaScript codebases somewhat more maintainable.

And at least garbage let you make international calls with the money you put into it. Nitro-saturated sewer water gives you what—a bit of extra bandwidth utilization, 2 free tokens to prove you’re above the poverty line, and discounts on paid cosmetics?

While it’s true that they’ve been trying to stop emulators for a long time, they haven’t been able to do too much about them because of Sony v Bleem.

Modern emulators exist in a legal gray area, though, and might be violating the DMCA. The more of these assholes that pop up and get sued, the higher the likelihood that one of them refuses to settle, gets steamrolled by Nintendo, and gives them and every other console manufacturer the legal precedent that emulators are piracy/DRM-circumvention tools.

Even if you disagree with my belief that Nintendo would be less aggressive this year if people hadn’t been spotlighting emulation-based piracy and provoking them, you should be concerned about that.

Oh, I’m aware. Much like intentionally losing part of your leg to trenchfoot in a desperate attempt to get out of being mowed down by a barrage of bullets or burned alive by mustard gas or chloramine.

It’s still not a pleasant time, though.

Nope…