danhakimi

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?

If you are talking about something like openauth (where you sign into some random website using your Google account) yes, but your base identity is still tied to Google. So if Google goes down, you lose your google account, and you also lose your account at every other website you logged in to using your google account.

Yeah, essentially that. The back-up plan in case your instance goes down is a separate issue, my main plan is just that users shouldn't need a new account for each fediverse application they want to try, considering one account is already able to make any kind of post.

couldn't your instance just serve your identity to other instances?