danhakimi @ danhakimi @kbin.social

Hi all. I'm Dan. You can message me on Matrix [@danhakimi](https://kbin.soc

---

Read more

Posts

7

Comments

431

Joined

2 yr. ago

whatsapp for family, because that's where family is.

nobody uses facebook to connect with family, they use facebook to connect with people from high school they haven't seen in 15 years and don't care enough about to actually keep in touch.

wait, is "buddy" gendered?

I like to mix it up. but language is context dependent. "buddy" is a go-to of mine, and feels entirely gender neutral.

"my people" is good for plural.

"friend" is good as long as you have the right rhythm with it. Like, you know, in the second person, like "hello, friend."

"bro" obviously doesn't work, but I have casually referred to trans friends as "broham" and they didn't seem to mind. I don't do it often, but sometimes mixing in a good bro pun is more fun that way... go a little over the top, call somebody brobrahk brobrahma, nobody's going to be thinking that you're implying gender, it's an equally ridiculous term to call anybody by. Similarly, although context dependent, there are implicitly feminine words you can use, although some of them can be degrading in the wrong context. "Gurl," "bitch," and "slut" can work, as long as it's ridiculous enough in context not to be taken seriously. I'm a guy, I've had friends call me these. "Gurl" might not be the best for a nonbinary friend or a trans man friend, so be careful with it.

I don't know, I only have a few nonbinary friends, I guess, and I mostly refer to most of them by their names.

in addition to you being an asshole, you're also wrong in practice about how HR teams work. If they hear about shit like this, they really do try to do something about it. Sometimes they can't really accomplish anything, and they're just bureaucratic about it, but no, they do not think of the person making the report as a problem, they think about the person actually causing the actual problem. Hostile work environments are unproductive, are bad for employee retention, and have a heightened risk of law suit. Only shitty businesspeople think the problem doesn't exist as long as it's not on paper.

OP's better off if their employees steer clear of them—that much is obvious, isn't it?

op mentioned the DSA...

well I said "would." It's not a moral issue, it's just confusing that people find this compelling. It doesn't quite seem like a collaborative artistic experience. It seems more like just bad tech.

I don't understand why this would exist over noscript + using the websites you actually want to use. If you want to spend time on minimal websites, there's no reason you can't use html and http to do it.

it looks like this was a college student's weekend hacking project and some people took it way too seriously and now have this social idea about how intentionally inferior tech is going to revolutionize... devolutionize? the internet. This is not snapchat. This is cave painting.

why?

If you are willing and able to enter a partnership like Samsung, you can do it fully (including encryption support etc).

Samsung can interoperate. We cannot. We cannot enter into partnerships with Google. We are people, Samsung is a massive corporation. You understand the difference, right? Google will not let us access their servers. They're not making it difficult, they're not making it possible at all.

you don't just need to support the protocol, you need a server to communicate with your client, and Google is not here to federate its RCS service with Bob's summer Github project.

Matrix is the federated messaging network. It's also end to end encrypted, although people have pointed out issues with server security and with metadata—which is why they're working on peer to peer tech.

RCS is not similar to any federated technology at all. It's operated exclusively by Google in the US and most other countries. The technology was created, from the ground up, for carriers. But even carriers couldn't actually make it work in practice, so they asked Google to take over. It's a fucking albatross. We, as a society, need to drop it.

Google is the exclusive RCS provider for all carriers in the US and many other countries. The desire for an AOSP android API is for developers to be able to write clients the way they do SMS clients, not to replace Google's servers—that's a pipe dream. IIRC, Google actually helped Samsung develop RCS support in their app. I'm not sure why it's so difficult to implement.

There is an RCS test app, we could theoretically modify that, but I guess nobody has for some reason. I don't particularly want people to use it, Matrix makes so much more sense.

It's kind of open. It's pretty much open for carriers to implement on the server side, and for OEMs to develop on the client side. There is an open source client in AOSP's RCS Test App, but for one reason or another, as far as I know nobody's attempted to implement it in an actual usable client app. I don't believe there's a server reference implementation. And, in the US, all the carriers' RCS services are run exclusively by Google, so there's no real point in attempting to set up your own server. Apple might be able to navigate the politics with carriers and with Google to make something work, if it wants to, but it's really not a standard for us to play with.

Use Matrix Instead.

I disabled the Google App back when "Google Now" was still a thing. Remember when it would give you directions to get where you were going after you were already on your way? I'd be on the train, it'd tell me "oh, you wanna go somewhere? Get off the train, take a cab to the nearest train station, get on the train..."

They removed everything but sports score tracking, I kept using it for a while, and then I realized that I could just fucking use my browser for search, since that's where I wanted to read search results anyway. And that's what I did.

They're going to keep doing this again and again, making their app worse and worse.

No idea why I would ever want the Google app back.

I'm not saying "yes, you currently can do this with the activitypub protocol as it is," I'm saying this feature could be added to activitypub, and I've made specific references to protocols like POP and IMAP that handle logging into email servers from various client applications. I'm not going to code it myself, I'm an attorney, but I do know enough about computer science to know that there is no computabilty issue with my proposal, and that you dislike it primarily because you don't currently have an idea for implementing it, which is not my concern at all.

What does that mean? When you post, who’s server’s outbox do you post from? Inboxes and outboxes by server are a central part of the standard.

The server my account is stored on.

or any other, I don't give a shit, I'm not sure why this would make a difference, but that seems like the obvious answer to me.

You can copy over a user, and make another similar account (like pixelfed), or you can do stuff on that server from another federated server, but at the end of the day you’re not on the same account on different servers.

I don't know why the current pixelfed app needs to make a separate account.

I gather it finds that solution most convenient, as it means the fewest interactions with the Mastodon server, and there's currently no straightforward for the current pixelfed app to establish a secure long-term session with a non-pixelfed server. I understand that it currently does make a separate account.

I don't understand why it is inconceivable for the activitypub protocol to support such communication. eMail has multiple standards that let me log into Thunderbird from non-Thunderbird email servers.

Sure. It’d be a pretty huge departure, though. To a weird degree, like Coca-Cola leaving the beverage business becoming a tire company.

If you wanted to make a new protocol, you could go beyond federation and have a fully decentralised system where everything happens on arbitrarily many servers in parallel, but that would be a lot of work and probably data-heavy before any users walk through the door.

I feel like you're describing something I'm not calling for. I'm not calling for accounts to be mirrored to multiple servers. I'm calling for a system where client applications can access different servers without copying accounts to a more familiar server.

If you had some centralised way to handle accounts it wouldn’t be federated anymore.

So why can't you have some federated way to handle accounts?

but either way it wouldn’t be ActivityPub-complient.

Unless you changed activitypub, right?

OPs suggestion that you can just move between instances with the same account isn’t how the fediverse works.

I'm OP.

I'm not sure why you're speaking in the present tense about a suggestion I am making for the future.

alright, well that's not great, but my point is more that we could update the protocol to allow this to be done securely and conveniently.

You can log into a pixelfed app on android with a mastodon account. Why can't you log into a pixelfed web frontend with a mastodon account? What law of physics makes that impossible?