There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Why can't we have a unified API across the fediverse to use in mobile apps?

Is there a reason why all the services, that use the ActivityPub protocol don't have a unified API?

None of the mastodon apps allow me to log in with a lemmy/kbin account.

Also none of the lemmy apps allow me to log in with a kbin account.

Even though kbin has both mastodon (microblogging) and lemmy (threads, communities) functionality.

Also, Pixelfed recently introduced "login with Mastodon", but all it really does is just create a new user on it's instance and copy over the mastodon followers and profile info.

Why can't we just have one account to rule them all?

cupcakezealot ,
@cupcakezealot@lemmy.blahaj.zone avatar

Pixelfed actually got a sign in with Mastodon account working:

mastodon.social/

adonis OP ,
@adonis@kbin.social avatar

yeah... and all it really does is create a new pixelfed account, while copying over the mastodon bio and followers.

melroy ,
@melroy@kbin.melroy.org avatar

Only if W3C people thought about all this.. before releasing ActivityPub protocol to the public.

pewgar_seemsimandroid ,

b

skullgiver , (edited )
@skullgiver@popplesburger.hilciferous.nl avatar

deleted_by_author

  • Loading...
  • rglullis ,
    @rglullis@communick.news avatar

    With extensive work, these tools can all be made to work together under a single username. Every tool needs to be made aware of every other tool, and a lot of the actual federation code needs to be externalised to an all-encompassing server. This can be done without breaking any spec and without becoming incompatible with the rest of the Fediverse, but it’ll require a LOT of work.

    You basically summarized my original plan for communick. The basic idea is:

    1. Take the existing services, provide commercial hosting
    2. Use the revenue to fund development of protocol-level integrations, contribute back to open source
    3. Build tools to make it easy for companies to migrate away from Facebook/Twitter/Instagram/WhatsApp and own back their internet presence again
    4. ???
    5. Profit / Destroy Big Tech.

    Unfortunately, the amount of people willing to pay for commercial providers of social media is embarrassingly small, so I am stuck at step 1 and the best I could do is to build a SSO system for Matrix/Mastodon/XMPP, to let people use the same credentials on all “communick.com” servers.

    skullgiver , (edited )
    @skullgiver@popplesburger.hilciferous.nl avatar

    deleted_by_author

  • Loading...
  • rglullis ,
    @rglullis@communick.news avatar

    imagine tech brand like LTT coming in with a federated forum for customer/community interaction

    Exactly! This also applies for old media as well. Why is it that the NYT, WaPo, WSJ, Deutsche Welle, Globo, Telemundo, Forbes et caterva haven’t still set up their own AP servers? I guess they seem as more interesting to go to Twitter and bitch about Elon Musk instead of just emptying the platform? Why can’t they become providers of a service and say “all subscribers get a free account”?

    skullgiver , (edited )
    @skullgiver@popplesburger.hilciferous.nl avatar

    deleted_by_author

  • Loading...
  • rglullis ,
    @rglullis@communick.news avatar

    the entire Fediverse is equal to what, two percent of Twitter’s userbase?

    I’d honestly say it’s even less and I’d even wager that the amount of bots here are even higher (percent-wise) than Twitter. I’m working on a search engine for the fediverse now, and I was surprised with the amount of bot accounts and mirror servers that I am finding.

    you don’t want a journalist’s socials to be in the hands of their boss.

    I feel quite the opposite. If a journalist is really independent, then they can go on to host their own content. But as long as they are writing under the editorial guidelines of some larger institution, I want this association to be well defined and transparent.

    People don’t want Twitter do die and wither away.

    I am fundamentally opposed to any ad-funded business. I honestly believe that moment a lot of the issues in our society can be traced back to the moment that we made it possible for people to make a living by just collecting eyeballs instead of focusing on quality work at a small scale. So, yeah, I very much want Twitter/Facebook/Google to die and wither away.

    shrugal ,

    Because they are still different apps with different needs, architectures and formats. They just synchronize most of their content between each other.

    adonis OP ,
    @adonis@kbin.social avatar

    they just synchronize

    But to be able to sync with each other, they still have to agree upon a standard, right?

    shrugal , (edited )

    Yea, but that’s just a lowest common denominator (e.g. it doesn’t include things like lemmy community sidebars), and also generally not appropriate for a client application. ActivityPub transmitts all events that are happening (posts, likes …) between servers, and they are supposed to index and aggregate things (e.g. sum up votes, sort posts). It’s just not feasible to expect the same from a mobile app for example, you’d have to at least create another standard for that.

    So services end up implementing their own client APIs to fit their needs. And imo that’s actually a good thing, because it allows them to try out features and specialize on different use cases. But afaik the ActivityPub people are working on another standard for client APIs, at least it’s on their radar.

    ShittyKopper ,

    ActivityPub has a C2S (client to server) API in addition to the S2S (server to server) API, it’s just that nobody cared about it to implement it. And because nobody implemented it nobody iterated upon it so now it sits as this underspecified (and unusable) state.

    CombatWombatEsq ,

    We’re working on it! Here’s the spec-in-progress: www.w3.org/TR/did-core/

    These things take time. We’ll get there.

    Wats0ns ,

    Barely understood it, but thanks for your work!

    Steve ,
    @Steve@compuverse.uk avatar

    A unified API and a single login, are two separate things.

    A single federated authentication could be a good idea. But the various federated services are different enough that they should have different APIs.

    Tatters ,

    Yes, they are completely different things.

    masterspace ,

    OP is just asking why they a third party mastodon app can’t login to a Lemmy or kbin server, which is a valid question.

    From an authentication standpoint there’s no reason for their auth flows to be at all different or use different endpoints relative to their domain.

    The returned profile or account object might have different fields which could cause an app to crash, but there’s no reason for every fediverse app to not use some of the same basic schemas and endpoints.

    DoomBot5 ,

    Here is the reason: xkcd.com/927/

    joel_feila ,
    @joel_feila@lemmy.world avatar

    Fine ill go make my own standard but with black jackc and hookers

    Callie ,
    @Callie@pawb.social avatar

    There is a comic for everything

    Crul ,

    I’m not an expert, those who know more, please correct me.

    Regarding logging-in with one account into another instance, I think that’s not how it’s intended to work. But I’m oot sure I understand what you’re asking.

    Regarding the unified client API, 2 days ago Manton Reece (Creator of Micro.blog) wrote a response to Dave Winer’s open voicemail in where he says:

    There is a lot of work to do, even outside of ActivityPub. As Dave mentions, we also need a common posting API. The most popular Mastodon client apps do not support either ActivityPub or Micropub. But a lot of progress can be made focusing on interoperability for the server-to-server part of the API. That should be the top priority with Threads set to join the fediverse.

    adonis OP , (edited )
    @adonis@kbin.social avatar

    logging in with one account into another instance

    I'd imagine a OAuth/JWT-like workflow, where pixelfed.social can ask a kbin-API whether my user exists on kbin.social.

    If it does, I should be able to post images on the pixelfed app that show my username as @adonis.

    Edit: by @adonis, I mean adonis @ kbin.social

    cwagner ,

    deleted_by_author

  • Loading...
  • adonis OP ,
    @adonis@kbin.social avatar

    Why would there need to be a signature to every post? According to your statement, any service that provides OAuth/JWT would be prone to this fatal flaw, wouldn't it?

    cerevant ,

    No, because the model for ActivityPub is very different than how OAuth is used for authentication. What you describe is like wanting to log in to hotmail using your gmail account, and being able to send and receive e-mail from your gmail address.

    It is a fundamental to ActivityPub that a user exists at a domain, and content coming from or going to that domain is sent from / to the relevant server at that domain.

    Federated login is a good idea, and it’s been done, both in closed and open forms. Combining federated login and federated ID over ActivityPub would fundamentally change ActivityPub.

    Crul , (edited )

    If it does, I should be able to post images on the pixelfed app that show my username as @adonis.

    It cannot work as stated because there could be another @adonis accounts in other instances and the only way to prevent that would be to centralize all the signups which goes against the whole idea of decentralization. That’s why the user must be @adonis1 as it is shown now.

    Regarding the OAuth/JWT, again… not an expert, but what I understand is that that kind of integration is much stronger than the current system. AFAIK, it could work as you say, but that would make things much more complex for the servers; you usually provide OAuth authentication for a few services, I don’t know how well that scales with … hundreds / thousands (?) of authentication provders. But, who knows, maybe in the future it’s implemented in one way or another.

    We should take into account that this technology is fairly new and people are still building on it.

    adonis OP ,
    @adonis@kbin.social avatar

    Sorry but the autoformatting miscommunicated my statement... by @adonis I meant adonis @ kbin.social.

    And the domain is always part of the actual userhandle. Hence, there can only be one.

    Regarding OAuth/JWT, these aren't new concepts. They've been around for while, if not decades.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines