#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
#
aaronpk
what exactly is an activitypub server then?
#
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
#
Loqi
again has -1 karma over the last year
#
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