#social 2019-11-18
2019-11-18 UTC
sl007, ajordan and ayorosmage joined the channel
# 
ayorosmage Hi
# ayorosmage ActivityPub permit to create federation. Federation is described as a way to prevent "one big company to own all the data". Thus, as far as I have understood, with the ActivityPub protocol data are sent through all the federated servers and then each server saves the received data locally. But considering the privacy
# ayorosmage sharing data (and potentially private ones) across multiple federated servers isn't it in some way... worse ?
# 
jaywink[m] Federation isn't really a tool to improve privacy, so in some situations yes that would be correct.
# jaywink[m] it depends really which centralized service you replace with federated ones and how both sides of that switch handle the data
# ayorosmage Thanks for your answer
# ayorosmage On https://fediverse.party/en/fediverse/ page it says
# ayorosmage "You can choose the person who will be in charge of your data - the administrator of your server"
# ayorosmage But it's false right ? It's not only the administrator of my server who is in charge of my data. It is also all the federated server that received my data ?
# hankg[m] > <@irc_ayorosmage:cybre.space> sharing data (and potentially private ones) across multiple federated servers isn't it in some way... worse ?
# hankg[m] It's a little more complicated than that too. For public data it's of course public anyway, but it is still disaggregated. Wouldn't stop someone with resources and intent from reassembling it all but it's not a one stop shop.
# hankg[m] Where federation gets different is the distribution of private/limited distribution posts. Those do not propagated across the whole federation (honestly in practice neither do public posts/comments) but instead can be thought of more as e-mail-like distributions. With proper security on the servers (which isn't a given) it would be much harder to properly sip
# hankg[m] Lastly without being able to search the social graph directly a lot of inferences that can be made by mining (legally and within TOS parameters even) social graphs of Facebook is a lot harder
# ayorosmage Ok thank you for you answers
# ayorosmage I agree with the fact that messages doesn't propate the whole federation
# hankg[m] Sometimes even when you want it to lol
# ayorosmage But if I take the example of mastodon, it seems mastodon own the vast majority of the post
# ayorosmage ^^
# hankg[m] "Mastodon" isn't a unit though. For example I'm on mastodon.technology (a pretty big instance) but there are whole parts of mastodon that I don't "see" without specifically going out to those other servers
# ayorosmage Then in practice, it have the feeling that there is on BIG server and a cluster of little federations
# hankg[m] Honestly when I put myself in the shoes of my ~70 year old dad I don't think it looks enough like one big entity for it to be not confusing to him.
# ayorosmage Ok. I have very few experiences about Mastodon for the moment
# cambridgeport90[m] Thank you for noticing this. I have as well. Then again, a lot of servers seem to have the standard list of blocked domains. Good for them, considering what subdomains often stand for.
# ayorosmage I also have question about the "open source" and the business models
# ayorosmage I have the feeling that open sourcing is quite a "requirement" for federated app
# ayorosmage And most of them (all ?) have no ad
# cambridgeport90[m] The business model is up to the incense holder, if there are any. Open source? It’s a benevolent dictatorship for life from what I understand.
# hankg[m] Ideally instances remain small enough and federate so the costs are more negligible
# ayorosmage Most of them seem to have a patreon (whith quite fewer donator actually)
# hankg[m] cambridgeport90: ActivityPub is not a BDFL...Mastodon core is but like anything open source could be forked
# cambridgeport90[m] > <@jaywink:federator.dev> it depends really which centralized service you replace with federated ones and how both sides of that switch handle the data
# cambridgeport90[m] It does.
# ayorosmage Yes but if it is forked it can be uncompatible with the actual federation
# ayorosmage And starting a new community is hard (specially for social networks)
# ayorosmage Thus De Facto it is BDFL no ?
# hankg[m] It could be but not necessarily. A lot of systems interact over ActivityPub already quite well
# hankg[m] If you see me on Mastodon it's not me tooting from a Mastodon instance it's me Tooting from the Friendica platform which has a totally different code base
# hankg[m] they federate to each other over ActivityPub
# cambridgeport90[m] I’m actually going to be setting up an environment like that soon. I’ll tell you how it goes.
# ayorosmage okay i will take a look of how it works
# ayorosmage ok thank you !
# ayorosmage Another question (sorry)
# hankg[m] > <@cambridgeport90:matrix.org> I’m actually going to be setting up an environment like that soon. I’ll tell you how it goes.
# hankg[m] Like what?
# ayorosmage How a server can setup policy according the other servers of the federation it will interact with ?
# ayorosmage Is it a "manual" process
# cambridgeport90[m] > <@irc_ayorosmage:cybre.space> Is it a "manual" process
# cambridgeport90[m] The main thing you can do is set up a domain block list.
# ayorosmage Or is there maybe of system of tag like "everything", "not safe for work", "no political content", etc... ?
# ayorosmage Ok so we have the choice between a white list or a black list
# nightpool[m] ayorosmage well the first thing to understand is that there are two paths for servers to discover your content
# nightpool[m] #1, which is the most common path, is for you to tell them about it using POST, when you create it
# nightpool[m] so for example, when I make a status on Mastodon, it POSTs that status to all of my follower's servers.
# nightpool[m] in that case, there's no need to set any sort of policy, because I'm sending my message to every server individually
# nightpool[m] #2 is for the remote server in question to look up my content by URL. for example, this is how you find people on the fediverse—someone sends you a link, and your server resolves that link into a user it can then send and receive messages from
# nightpool[m] this is harder to restrict, because it's almost impossible to prevent someone from linking to your posts and sending that link to someone else. And if your content is available on the internet, someone else can access it.
# nightpool[m] there are best effort workarounds you can put in place—refusing to serve content to some IP addresses, or by user agent header, but there are no guarantees
# nightpool[m] ayorosmage: does that help clarify things?
# ayorosmage Yes thanks a lot.
# ayorosmage If a resume in the case #1 there is an (asynchronous) server A => server B communication
# ayorosmage And in the case #2 there is a (synchronous i think) server B => server A request
# ayorosmage Is that right ?
# nightpool[m] yep
# nightpool[m] although synchronous/asynchronous depends on the implementation of the given server in question
# ayorosmage Yes I agree, I was refering to
# ayorosmage "For federated servers performing delivery to a third party server, delivery SHOULD be performed asynchronously, and SHOULD additionally retry delivery to recipients if it fails due to network error."
# ayorosmage Of the activity pub recommandation
# ayorosmage If I understand well, another difference between case #1 and case #2 is that in case #1 the Post is certainly stored on both server A and B. In the case #2, the data is stored on server B and is just transcient on server A
# ayorosmage Is that right ?
BitBot joined the channel
# nightpool[m] depends on the server
# nightpool[m] and the context
# nightpool[m] in mastodon, any post that's referenced by another post is dereferenced and then stored on the server.
# nightpool[m] so for example, if I boost your post, mastodon will look it up and then store it, so it can display it
# nightpool[m] that's case #2, but it's still stored on the server, instead of being transient
# ayorosmage okay thank you
# ayorosmage I'm playing with mastodon and I wonder how the search is working (user for instance). Is there a discovery mechanism ?
# nightpool[m] no, it's just searching users it already knows about
# nightpool[m] Mastodon includes a way to go from (username@domain) => ActivityPub actor URI but nothing other then that
# ayorosmage Yes but if I search for a user, I also have the list of other users whose name fuzzy match including users on other federation. That mean Mastodon need to have the list of users locally
# nightpool[m] right, those are just users your local server already knows about
# nightpool[m] i.e. ones that other users have followed, or ones that have interacted with local users
# ayorosmage Okay It's much more clear right now
# ayorosmage thanks a lot
# nightpool[m] no problem!
# trwnh hmmmmm. that gives me an idea for note/article distinction where note is intended as a message and article is intended for sharing... >[08:02:26] <nightpool[m]> trwnh: discord chat messages are unambiguously Notes, but they have rich text formatting
# trwnh it certainly does make sense to say that messaging is like passing notes back and forth
# trwnh and that does seem to be a much clearer / less ambiguous division than length or formatting
# trwnh but is a youtube video really a page? you're linking to a dynamic resource (watch?v=id), not an actual document (video.html). >[12:27:55] <heluecht[m] Concerning this "Link instead of Page": "Link" type has got fewer parameters. And since we are referring to a page, this should be okay.
# trwnh i would actually use Link "preview" property for that
# trwnh you could then describe a Page/Video entity within that preview property
# trwnh the preview Object can contain whatever properties you want, no need to worry about how few are part of the Link then :) and as long as the top-level attachment is a Link then it should be clear how to parse it for implementations that don't support/understand attached Page or Video without id
ayorosmage joined the channel
# heluecht[m] trwnh (IRC): The "link" hasn't got that much fields. Especially there is no "Summary" field there.
# heluecht[m] And don't we link to a web page?
# trwnh it doesn't matter if the Link doesn't have a summary -- you can attach a summary to the object in "preview"
# trwnh functionally you are attaching a Link to the post, and therefore that attachment should be a Link
# trwnh if you want to provide a preview, then maybe actually use "preview" on that Link, is all
# heluecht[m] But if the page doesn't have a picture - which type should I then use for the preview?
# heluecht[m] BTW: Concerning other implementations: I did some tests, and both Mastodon and Pleroma do have problems with each "Page" and "Link" type.
# heluecht[m] I think that having an "attachment" array with a "link" object which in its "preview" has got some "page" object which then has got some "icon" field with a preview picture is nested too much.
sl007 joined the channel
# trwnh i don't think it's too nested, each layer still makes sense. you only have two levels of nesting, one for the attached Link and one for the Object inside the preview
# trwnh it's basically Object > Link > Object
# trwnh Object['attachment'][0]['preview']['icon'] assuming the first attachment is a link
# trwnh it's not only straightforward but also semantically correct -- if you want attachment 0's preview icon, then that's what you parse for
# trwnh if you remove the Link from the nesting then you end up with Object['attachment'][0]['icon'] which doesn't tell you that it's for a preview
sl007 and ilmu joined the channel