#social 2018-03-20
2018-03-20 UTC
# 
@JaysonElliot @Jason @facebook My dream is to see a real Social Media Protocol, just like we have for HTTP, email, etc.
There are proposals at the W3C now. Social networks should be cross-compatible, so no one loses out if they don't want Facebook, or any other walled garden.
https://www.w3.org/TR/social-web-protocols/ (twitter.com/_/status/975886758322749440)
Sveta, xmpp-social and timbl joined the channel
# 
fr33domlover saranix, I have a thought!
# fr33domlover Actors are required to have inbox and outbox, BUTTTTTTTTTT
# fr33domlover They don't have to be named that way in the URL!
# fr33domlover For example suppose in my app I represent users' projects as actors
# fr33domlover Since projects don't need to do their own access like GETing their inbox or POSTing to their outbox, all they need is:
# fr33domlover 1. people GET a project's outbox to read updates, changes etc. in the project
# fr33domlover 2. people/server on their behalf POSTs to a project's inbox to make changes and activities
# fr33domlover Now imagine a project at https://URL has its inbox at https://URL and its outbox at https://URL/changes
# fr33domlover That's very much like plain REST!
# fr33domlover You POST to a resource to change something,
# fr33domlover And you GET from URL/changes to get a list of updates etc.
# fr33domlover (while GETing from the resource URL gives the resource itself, not the change history)
# fr33domlover That way I can make as many actors as I want, for free!
# fr33domlover As long as these are problem domain entities, I mean, like projects or tickets or whatever
# puckipedia fr33domlover: I think the issue is that saranix doesn't want the inbox/outbox to be implicitly specified
# fr33domlover puckipedia, hmm what do you mean by implicitly though?
# fr33domlover I mean ActivityPub requires to discover them
# fr33domlover In RESTful web apps in general
# puckipedia yes, but what if the spec didn't require that, and just allowed you to e.g. POST directly into a collection
# fr33domlover puckipedia, well but that seems *possible* to me right now
# fr33domlover Because
# fr33domlover What if the inbox URL is the actor ID
# fr33domlover Hmmmm
# fr33domlover Oh I see what you mean
# puckipedia yeah
# fr33domlover Hmmmm
# fr33domlover Let's find an example
# fr33domlover Say you want to follow someone
# fr33domlover You POST to their Followers collection?
# fr33domlover (I mean server A posts to the Followers collection of the actor on server B?
# fr33domlover Rather than posting to the actors inbox?
# puckipedia well, more like you POST directly to the actor
# fr33domlover puckipedia, but that already works, define an actors inbox to be the same as their ID
# saranix Follow is even more magical, so magical it has "side-effects" (call your doctor if it lasts more than 4 hours :-P)
# fr33domlover saranix, ActivityPub allows actions to have side effects - and it has to!
# fr33domlover otherwise actions are plain reports
# fr33domlover And never *commands* to change something
# fr33domlover Side effects are essential
# saranix actually, side effects are just sugar for clients
# fr33domlover "I ate a banana" doesn't need a side effect, it reports an AFK event
# fr33domlover But "I want to open a new ticket" needs a side effect
# saranix server->server, it honestly doesn't matter if there is a "followers" collection... it's all very twitter
# fr33domlover A new ticket being open etc.
# fr33domlover saranix, followers are not required
# saranix that's what the side effect is!
# saranix The side effect is the addition to the followers collection, but here's the funny part, that's not even required! The collection doesn't even have to exist because you aren't required to give anyone permission to it! not even the owner!
# saranix (which is good BTW)
# fr33domlover saranix, follows/followers is SHOULD not MUST in ActivityPub
# fr33domlover It seems
# saranix exactly
# saranix still magic though... if a wizard casts a spell in the forest, and no one is there to see it....
# fr33domlover saranix, what other way is there though?
# fr33domlover I mean, how to define the special purpose of an activity
# saranix lol, the protocol need not specify
# fr33domlover Other than a side effect
# puckipedia saranix: oh and the follower behavior changed btw
# saranix I think it's overreach
# puckipedia saranix: it's specced to not do anything if you send a Follow
# saranix way too much twitter like
# puckipedia but you may get an Accept/Reject back, some time in the future
# fr33domlover saranix, Following is used for delivery of updates, idk if that's a good enough reason but it's definitely not a bad one
# fr33domlover I mean,
# fr33domlover following is how updates on stuff get propagated in the network
# puckipedia fr33domlover: the thing is that 'following' is quite a twitter-centric way. Stuff like Google+ etc have many separate lists of people you can send updates to
# fr33domlover puckipedia, hmm yeah Diaspora* has its own model too, you define Scopes
# fr33domlover That's true
# fr33domlover Good point
# fr33domlover puckipedia, but when you "follow" someone it's like a request to see their stuff
# saranix hubzilla is more more free... you have only "connections" with "permissions" (very LD-OCAP ready)
# puckipedia fr33domlover: a lot of ActivityPub isn't clearly specced, "Following" is a request to get added to their "followers" list, which will give you access to posts that are addressed to that list
# fr33domlover Maybe we can think of followers as a conceptual inbox for defining scopes/groups
# fr33domlover Suppose you have a Familt group
# fr33domlover And Friends and Coworkers etc.
# fr33domlover And then some person from the internet says Hi you seem interesting I want to follow you etc.
# saranix puckipedia: "addressed to that list" --- this is where I think the protocol is way too twitter-minded
# fr33domlover You don't necessarily want to put them in those groups yet
# fr33domlover So followers is like a default
# fr33domlover "people possibly including random strangers, who want to see what I post"
# saranix fr33domlover: don't you see, the stuff you are talking about is very implementation specific. That's why I say it's overreach. The protocol has no business defining internals, all that should be necessary is federating
# fr33domlover saranix, tbh I never used twitter so cant compare :p
# saranix fr33domlover: I never used twitter either, the comparison is that it does not allow all the other things in the universe that exist besides twitter, it just assumes your thing works like twitter
# fr33domlover saranix, hmm well let's see what federation means though
# saranix no it isn't
# fr33domlover saranix, hmmm do you have an example, maybe something you made or other thing, that works in a different model and can't use ActivityPub for federation?
# puckipedia the thing is
# puckipedia some stuff that implements ActivityPub already assumes that 'followers' is the only collection you'll ever send posts to
# fr33domlover hmmm puckipedia that sounds wrong
# saranix it's not that ActivityPub can't be used, it's that when you add all of these extra symantics on top that are not ACTUALLY IN THE SPEC, that causes problems
# saranix "some stuff assumes" "that sounds wrong" -- yes.. it is very wrong but also true. Mastodon in particular has this habit
# fr33domlover Hmmm let's take Diaspora* I'm curious how it could solve that issue
# fr33domlover Diapora* lets you define Scopes, groups of users you share with i.e. they can see your stuff
# fr33domlover there is no concept of following there
# fr33domlover You can just choose to share with a person
# fr33domlover Can't make a request to follow them
# fr33domlover i.e. the opposite direction
# fr33domlover When you share with someone, then you can see their content (if they approve the request)
# fr33domlover But Diaspora* does have a default group, i.e. a list of people you've shared with
# fr33domlover Hmmmmm
# saranix let me stop you right there. default group, has a group, not a group, all of these are internal details, the federation protocol has no business knowing or caring about these things
# fr33domlover saranix, then what should federation involve?
# fr33domlover I mean
# fr33domlover What's left
# saranix passing messages, that's it, nothing else
# puckipedia the basic structures that cna be sent and how to send them between users yeah
# fr33domlover The first part is ActivityStreams
# puckipedia yeazh, but activitypub does explicitly say that messages should be send with AS2
# fr33domlover Whatever the second part is, there is a detail left missing - how to propagate stuff through the network
# saranix yeah, the structure == AS2, the passing = inbox discovery. Previous protocols in this space used AS and webfinger for historical reference
# fr33domlover saranix, but we still need something to do the role of WebSub
# puckipedia fr33domlover: HTTP POST, based on the addressing inside the activity, officially
# puckipedia fr33domlover: you do know that ActivityPub is a push-based protocol, everything you send is pushed from your server to the recipients
# saranix you'll never be able to stop randos from trying to POST to your INBOX. How you handle it is up to internals
# puckipedia like, think about DMs from someone you've never seen
# fr33domlover saranix, puckipedia I think I get your point :) Did you say something to the group?
# puckipedia I do not think there is specifically an issue with having an explicit 'followers' collection as you can just ignore it and reject follow requests. but, I do think that not being able to handle non-follower addressing is an issue
# fr33domlover We *do* need a standard way for people to ask "I want to follow you i.e. get updates on stuff you post"
# fr33domlover But yeah,
# puckipedia fr33domlover: what if the social network you're building does not have a concept of following
# fr33domlover It doesn't have to be based on followers colection
# puckipedia anyways, Kroeg handles all this properly at least
# fr33domlover puckipedia, semantically there may be none, but, as long as federation is push based, you have to have a concept of "who needs to receive a notification about my new post"
# fr33domlover I agree maybe follows isn't strictly required
# fr33domlover But something more or less like a list of followers/targets for sending notifications
# fr33domlover Is required
# puckipedia fr33domlover: you can address your post to any list, and everyone in that list will get a notification
# puckipedia at least, specwise
# fr33domlover puckipedia, hmmm I see - say we could even have these lists managed offline, like, I ask you here on IRC "hey add me to your list I love your content" so you add me manually
# fr33domlover Without anything happening server-to-server in activitypub itself
# fr33domlover Yeah good point ^_^
# fr33domlover The ability to request-to-follow-someone
# fr33domlover Is not required
# saranix technically not even collections matter... the envelope CAN have everything BCC,BTO (mine does), because there is no 3rd party routing (people want to force 3rd party, but 3rd party can only work with sigs, and sigs are not forced)
# fr33domlover saranix, puckipedia, have you discussed this with the editors of the spec?
# saranix everything mentioned so far has been discussed at length in our meetings, yes
# fr33domlover And any conclusions / latest progress on that? :)
# puckipedia iirc the reason this has been added (and I don't disagree, relatively speaking it's quite a large fraction of social networks) is because it's a pretty common usecase
# saranix lots of disagreements ;-)
# puckipedia and allows for some bandwidth optimizations in the most common case
# fr33domlover saranix, what are the arguments against what you said?
# puckipedia I would like to talk further but I have to go, see y'all later
# fr33domlover By the way note that I'd-like-to-follow-you *is* required for public content
# fr33domlover Like, anything capable of publishing world readabe content
# fr33domlover Needs to support "Ok you're following me now" automatically
# fr33domlover Without a person's intervention required
# fr33domlover However the "followers" list can still be private
# fr33domlover (that makes no difference though, when you send to your followers only you need to know who they are, nobody else has to know)
# saranix I might get in trouble for saying this, but whenever I bring up certain problems with the protocol, the response isn't a technical one, it's "mastodon does it such and such way", and "mastodon is the biggest implementation", one reason why you won't see for example the founder of Hubzilla in these meetings ;-)
# fr33domlover Aw that's sad
# fr33domlover I wish for everyone to work together :p
# saranix yeah ha
# saranix But anyways, the protocol itself is pretty solid
# saranix the things that are lame are all (thankfully) SHOULD and not MUST
# saranix some of them I had to fight pretty hard to keep that way
# fr33domlover I think it's good to have a variety of examples
# fr33domlover Like, varying approaches to federation and social networks etc.
# saranix variety is necessary for decentralization
# fr33domlover My own web app, I'm curious how it's going to be using ActivityPub and whether or not it will challenge its requirements
# saranix my own personal philosophy on federation is that it is "an agreement to be compatible"... but some people think federation is homogenization for the sake of compatibility...
# fr33domlover Well there's no escape from having *some* stuff in common
# fr33domlover I guess the big question is, exactly which stuff
# saranix things are inherently common, that's what brings about the desire to federate in the first place, *making* them common is wholely unnecessary
# saranix when I hear the word 'protocol', it makes me think of spy fiction where on person says to the other "I need to get a message to so and so", and the other is like "I'll drop it here, that's our protocol"... or after something goes down "don't worry, she'll be here, it's our protocol"... It's not law, it's not legislation, it's an agreement
# fr33domlover saranix, I sense a lot of frustration in you :
# fr33domlover :p
# saranix bahaha
# saranix I guess being the minority minority voice all the time does that too you :-P
# fr33domlover appoints saranix to be responsible for the SaranixPub protocol err oops agreement
# saranix you misunderstand
# saranix ActivityPub is not immutable either
# saranix it's not law
# fr33domlover Yeah sure I'm joking
# saranix My point being, that most people tend to create problems for themselves implementing or conceptualizing a federation protocol when they keep thinking that the internals have to look anything like the externals. They don't.
timbl and timbl_ joined the channel