#social 2020-01-12
2020-01-12 UTC
robin joined the channel
# 
robin Hello, I had a question about activity pub.
# robin Is it possible for a user to have one account on mutiple activity pub servers?
# robin For example if a user has a mastodon account, can this user re-use his account on a peertube server. So that if they upload a video it will be shared with their mastodon followers.
sl007 joined the channel
# trwnh robin: no. at least, not currently. accounts aren't part of activitypub. activitypub only deals with actors. it is possible to use the same actor on one server with multiple clients, but neither mastodon nor peertube are activitypub servers. they are simply apps that use the activitypub server-to-server federation protocol.
jesopo joined the channel
# melody that's sure a hair to split
# trwnh imo an activitypub Server implements both c2s and s2s
# cjslep[m] robin , another way to think about it: ActivityPub solves federating portions of an RDF data graph between instances, but nomadic/multi-homed accounts (having them exist in one or more places) is a different problem than the one AP solved. Maybe nomadic/multi-homed accounts could be solved using AP or some other specific tech. Unfortunately, nothing inherent about AP to help here. :(
# trwnh pretty much everything we have right now is a monolith
# trwnh back into users creating statuses).
# trwnh in mastodon's case for example, there isn't a discrete activitypub component in the server stack -- it just uses transformers between the internal database and the federation controller. you can't interface with the activitypub bits in mastodon, they're abstracted away. you are a user posting a status, not an actor creating a note. it's just that for federation purposes that information is encoded as Actor Create Note over the wire (and then transformed
# melody I think those are just implementation details, and not particularly important ones, I don't know that you could have usable software that was as thin a layer over AP as you're implying would be necessary for it to count, the AP and AS verbs and nouns are ontological abstractions, they aren't intended to be remotely useful for end users
# melody Communication over the wire is the important part, I don't see what part of anything implies that the storage component of a server, or the UI layer, should reflect or care about it
# nightpool[m] no, you definitely can have usable software, you just have to think of it as a thick client onto a thin server, rather then the other way around
# melody Nothing that exposed "Actors" unmediated to end users could be functional -- my point was that abstracting away the wire federation is a perfectly fine, the vocabularies are not meant to be presented unfiltered and not exposing the AP internals directly at a conceptual level shouldn't disqualify something from counting as ActivityPub
# nightpool[m] yes, but that's not the argument that's being made. the argument that's being made is that mastodon isn't a full AP server because it doesn't allow for pluggable clients, which I think is a reasonable argument given the scope of the spec.
# nightpool[m] you're assuming that the user would interface with the server directly, trwnh is assuming the user would interface with a client that interfaces with the server.
# trwnh yeah exactly ^
# trwnh the client can be an app that runs on a server
# trwnh like how you can use thunderbird, or you can use the gmail webapp
# trwnh except if i wrote an abstract messaging app that could send out over smtp xmpp or activitypub, is that a triple server?
# trwnh implementation-wise, i could have it speak c2s of all three protocols, or i could make it a monolithic app
# trwnh the user never sees the implementation details, though. as far as mastodon users are concerned, they have a mastodon account and they are using mastodon apps that interface with the mastodon api. the mastodon software is managing their profile, they have an account with their mastodon website. at no point does activitypub enter this equation, except for federation (which is subsumed into the federation controller).
# trwnh to be more precise, the original question about accounts on multiple servers doesn't really make sense because to have the behavior described, peertube would have to be a mastodon app instead of an activitypub "server". it would do oauth with mastodon, not with the activitypub bits.
# melody well activitypub doesn't specify any authentication at all
# melody and that's a small part of the larger problem which is that the C2S spec is just grossly insufficient for real use cases or people might be more interested in implementing it
# melody Given that both C2S and S2S are explicitly optional I don't think it makes sense to say that Mastodon isn't an ActivityPub server because well, it implements ActivityPub
# trwnh imap is grossly insufficient for electronic communication because it's not designed for that -- smtp handles delivery. but it's a moot point as long as there aren't any real generic ap servers that do only id assignment and delivery per the spec, nor any apps that can plug in as a client.
# trwnh i think the best examples in other protocols would be quassel for irc, or movim for xmpp
# trwnh quassel's core server is an irc client, but it is a quassel server
# trwnh movim is an xmpp client but it is a social server
# trwnh especially in movim's case, movim handles the status updates and the microblogging, but it uses the xmpp server for storage.
# 
jaywink[m] activitypub is more of a framework, not a strict spec - I don't see how there could be a true generic server? doesn't sound very useful as a platform imho
# melody A generic server doesn't make sense really, the C2S spec isn't robust enough to support a heavy client
# melody w/ a generic server
# melody it'd just be a stack of trash
# trwnh to me a generic server implements c2s and s2s and behaves roughly like what is described in the spec -- the Client does C2S POST and receives a 201 Created with the id, the Client can also define to/cc and the Server does the S2S POST
# trwnh what the client does with those ids is up to the client
# trwnh it's probably the kind of thing that would make much more sense if it were demo'd by example instead of discussing theoretical behavior
# melody the spec is too incomplete for that to work and be any good
# trwnh but the ap client would be the "core", logically speaking
# trwnh the server would be more like having a google account
# melody it'd be more like an unauthenticated SMTP relay on the open internet
# trwnh it would not be like smtp at all, it's more akin to imap really
# trwnh the potentially confusing ux would be having to have two accounts -- one for authorizing with the account on the client, one for authorizing with the actor on the server
# melody except authentication and authorization aren't part of the spec so a pure generic server shouldn't do either
# trwnh that's too literalist. how authorization is done is entirely up to whoever is implementing the server. you can say "my server requires oauth" or "my server requires username/password"
# trwnh just like how imap/smtp settings have to be defined for email clients
# trwnh which server, which port, which encryption (ssl, tls, etc)
# melody except those are part of the spec for imap and smtp
# trwnh is gmail's oauth2 part of the imap spec?
# melody no, and they are criticized all over for it and there's a bunch of email clients their shit doesn't work in because of it
# trwnh well the same isnt and shouldn't be true for the web equivalent of email for websites
# trwnh it's just that it's a new paradigm, all the existing email clients expect username/password
sl007 joined the channel
# trwnh we kind of already have interop issues with e.g. mastodon requiring HTTP Signatures or LD Signatures for certain things. or even just requiring https. or requiring webfinger which matches preferredUsername.
# jaywink[m] in the real world people want to make different kinds of platforms with different types of features - so there will always be interop issues, no spec can cover all cases
# jaywink[m] activitypub is flexible for this reason
# jaywink[m] compare to the diaspora protocol for example which is more strict and covers only a small set of features
# jaywink[m] it would never work for what activitypub does with tens of platforms with different features and needs
# melody Yeah, and AP's lack of specificity is helpful for that and I don't actually think it's a problem, I just think gatekeeping what counts as an AP server based on whether it implements the optional C2S portion is weird, since generic interop is already thoroughly impossible I don't see why a server can't still count as a server if it defines its own client API -- anything functioning would need to anyway by way of extensions at a minimum
# trwnh it's not a big deal, just a precision-of-language thing? it's the difference between "activitypub server" and "application that implements activitypub s2s"
# melody which is why my initial comment was "that's a hair to split", it's pretty pedantic and that pedanticness wasn't helpful to the question that was asked
# trwnh peertube to post to mastodon because peertube isn't a client of mastodon but also it doesn't have a way to be a client of the underlying actor. if it wanted to add mastodon integration it would have to integrate with the mastodon account instead of the activitypub actor.
# trwnh you can use activitypub server to mean "anything that implements s2s" but i feel like that's a very collapsed model. they're monoliths in the sense that the quassel monolithic package is a monolith -- it has a core and a client but no meaningful separation between them, and thus is basically an irc client. wrt mastodon/peertube it's not pedantic because the lack of separation is relevant to the question, and it's the entire issue actually. you can't use
# trwnh maybe it would make more sense if we considered a local-only instance of mastodon with federation turned off?
# trwnh or a hypothetical fork of mastodon that removed the federation controller
# trwnh in those cases there would be no activitypub at all
# nightpool[m] i don't think i follow everything trwnh (IRC) is saying, so I can't speak to that, but i do think the difference between "software that just implements activitypub s2s" and "servers that implement s2s and c2s" is really crucial for the question asked
# nightpool[m] "Can I use a youtube-like social media service and a microblogging-like social media service with the same account" is a really easy question to answer when you have thin servers and thick clients, and a very hard question to answer when the server hosting your account is fundamentally tied to a specific piece of client software
# melody I mean the answer is neither service would function
# melody thin servers and thick clients just means globally subpar experience and even worse interop issues
# melody + even less in the way of anti-harassment or abuse controls
# nightpool[m] would you say that browsers are a globally subpar experience and have worse interop issues compared to current activitypub?
# melody i don't think that analogy works
# nightpool[m] in my experience, the interop issues are better, because users can easily try out different browsers when one isn't working
# nightpool[m] it's the same model. ActivityPub clients provide a way to view AS2 content.
# melody also browsers are awful, and so hard to implement that there's only two left, i'm not sure that's a mistake anyone wants to repeat
# nightpool[m] i don't think it makes sense to call safari and chrome the same browser, even if they share an ancestor.
# nightpool[m] almost all of the internals have diverged
# melody i don't think there being 3 whole browsers instead of 2 really changes the salient point here
# melody and part of the reason everything has converged is because the interop issues were insurmountable without all browsers using the same core and users hated needing to use different browsers to access different websites and developers couldn't juggle them all to deal with their incompatible implementaions
# melody all of which sound like mistakes we don't want to repeat
# melody purpose-built servers which know enough about content expectations to normalize them for potential clients smooths things over
# nightpool[m] yes, and no-one is proposing adding complex layout algorithms or a runtime scripting engine to activitypub. The thing i'm saying is that "pluggable clients lead to a globally subpar experience" is an unsupported statement.
# melody I'm pretty sure browsers support my point better than yours
# nightpool[m] do they? There is nothing in the browser world that's at all similar to how activitypub is now.
# melody and the email ecosystem has also functionally centralized because thick clients are incapable of coping with unwanted content and they've been stagnant on features for years because of the interop challenges getting in the way of clients implementing new enhancements
# melody thick clients exacerbate interop issues unless there's few enough of them that developers can special-case behavior to handle the set
# nightpool[m] and thick servers don't?
# nightpool[m] "your client has to implement the extension" is not fundamentally any different from "your server has to implement the extension"
# nightpool[m] except the user can easily change one and not the other.
# melody purpose-built servers know enough about their own content to transform it for their needs, and that work can be done in a somewhat centralized place where multiple users can benefit from it, clients need to live on underpowered devices where they can't take advantage of economies of scale and are often also on harder network constraints, where servers could do additional filtering to prevent unnecessary data transfer
# nightpool[m] Backend-for-frontend is a type of client, nobody is saying this code literally needs to live on user's devices.
# melody i mean half the point of being federated over p2p is to be able to take advantage of some of these constraints on reality that way
# nightpool[m] The idea of the client/server distinction is the idea of that the processing you're talking about should be decoupled from the actual software that's hosting the content.
# nightpool[m] so that the processing can change while the hosting remains stable
# melody yeah, and i don't really agree, i think you'd see even more dangerous centralization if activitypub servers became glorified account & hosting providers, in part because servers becoming more content-agnostic would balloon costs for stuff like media storage
# nightpool[m] in what way?
# melody because servers no longer knowing what kinds of clients they will be interacting with will either be left behind for not supporting video uploads, as a for instance, or will need to pool resources to take advantage of economies of scale for more storage -- that's how gmail took over email -- long term
# melody servers being purpose built aids decentralizing in part because they can be selective about content and drop things they don't want to deal with
# melody and potential hosts can maintain better awareness up front of what kinds of service needs they need to provide for
# melody and can implement more specific strategies for offsetting costs -- like peertube trying to offset bandwidth costs for popular content by using a p2p network in the browser layer
# melody a generic server would not realistically be able to do that or at least, not while maintaining a diversity of implementations
# trwnh media storage can be done on the client tbh, or entirely external to the server. i see the server's real role as just assigning the id. linked data, basically.
# trwnh this is part of the id/url distinction to me
# trwnh in fact if the id is complex enough you practically require going through the client which can do access control and filtering there
# melody media storage can't be done in the client unless clients are always-available, but the reason we have servers is because they aren't, it has to be hosted somewhere
# trwnh clients can be servers too. quassel and movim are examples of this
# nightpool[m] sure, but the client could choose a different external service, or say "this media is only available through BT" or whatever.
# melody i mean fine, but i think that just recreates the existing structure but more complicated
# trwnh suppose you have an id of ap.trwnh.com/7203820382938303038201012 and a url of trwnh.com/image.jpg
# melody and makes the AP server even more superfluous because it's not actually providing any value anymore at that point if it's no longer hosting content either
# trwnh the thing is you can then update the url without breaking the linked data web
# melody making AP servers into glorified identity providers but without any actual auth specs seems like a really weird turn
# melody and servers that provided additional value would see more adoption than ones that didn't
# melody and you'd eventually centralize around the providers that could actually provide hosting & content storage at scale again
# trwnh content storage only matters for the json documents, the actual assets and media can be stored elsewhere at some url.
# melody and somebody needs to provide that -- an activitypub server that supported media storage would see more adoption than one that didn't, because it would be compatible with more clients that rely on media
# melody it'd be a storage race
# trwnh the only part of activitypub that really matters is the id, because that's what powers the linked data web. the client can host its own media and probably should
# melody again -- then you are just recreating the current structure, but with more complexity
# trwnh the complexity provides the benefit of using different clients
# melody if clients have to be servers with their own clients and then also be clients to activitypub servers that don't do anything it increases architectural complexity to no benefit
# melody and end-user device clients couldn't interop directly with the AP servers because they are intermittently available and content would be frequently gone from the network
# trwnh the benefit is being able to use the same actor
# melody i don't think that's enough benefit for the additional problems it causes
# melody you also end up with like a 4 party auth chain
# trwnh you could do it with 2 layers, idk where 4 comes from
# melody also using the same actor everywhere is often undesirable, people often want to present different identities on platforms with different purposes, i think if you were gonna try for a generic identity provider you'd also need to provide a lot of functionality for alias actors, but that becomes difficult with AP being tied so hard to the DNS system, people would need to congregate around large providers for additional pseudonimity
# trwnh i already do this as a quassel user for example -- i sign into my quassel core which is signed into and connected to various irc networks
# melody 1) the user as a person, 2) their client's client, 3) the server client, 4) the server
# trwnh in fact my quassel core lets me select one of multiple identities
# melody IRC is different
# melody IRC users don't resolve to a domain
# trwnh not terribly so -- there's a user/pass for the core, and then a user/pass for nickserv.
# melody IRC users aren't dereferenceable
# melody an AP identity provider is tied to its domain
# melody so if you wanted to retain pseudonimity you'd need to have an account on a large provider
# melody because an AP provider wouldn't be able to provide aliases on other domains
# melody the relationship a quassel core has to the idents it provides to IRC networks isn't really similar
# melody in terms of information leak
# melody and there's one less level of indirection because IRC doesn't really do media
# melody and your proposal would require most clients to actually be servers that also have their own clients so that there's a host separate from the identity provider to handle media
# trwnh if you're worried about anonymity you wouldn't use a personal domain though...
# melody that's my point
# melody there are incentives to clustering around larger identity providers
# melody beyond the normal incentives
# trwnh only because there is no generic widely supported way to use your own identity provider
# trwnh indieauth could be this
# trwnh openid promised to be this but was not generic enough or widely adopted enough
# trwnh still in cases where i *want* one identity i cannot have that
ajordan joined the channel