#social 2019-02-23
2019-02-23 UTC
# 
nightpool[m] mastodon requires webfinger to unambiguously map plain text, human readable representations of actors to actor URIs
# jdormit[m] FWIW Mastodon and Pleroma both support searching on the actual actor id as well, so you don't strictly need webfinger
# jdormit[m] Or you could bootstrap discovery by having an existing actor with followers Announce activities from your new actors
# rialtate[m] jdormit: inaccurate. mastodon requires the mapping to webfinger to exist no matter what, even if it has already discovered the actor
# nightpool[m] mastodon requires webfinger because it wants all actors to be mentionable by other users—otherwise it would be pointless to interact with them
# jdormit[m] Oh interesting. I thought you could also search by url
# jdormit[m] Actually now that I think about it, I was searching by the url AP field, not the actual id
# nightpool[m] you can search by url and id, it just makes sure there's a webfinger address additionally
# nightpool[m] i spent a lot of time writing this all up for mastodon's implementation report
# jdormit[m] Where is that published? And what was it for?
# nightpool[m] https://activitypub.rocks/implementation-report/
# nightpool[m] there are a couple of other notes I made on incompatibilities with the spec, but most of those have been fixed by now
# jdormit[m] Oh very cool, these are comprehensive!
# jdormit[m] I should maybe already know this, but are you a Mastodon contributor?
xmpp-social joined the channel
# cjslep[m] I forgot where this idea came about at FOSDEM, but one idea was to have an ActivityPub extension that hosts a Service (AP actor) at a well known URI that can point to peer services (followers/following?) as well as actors hosted on it's instance (some paginated collection).
# cjslep[m] its* (autocorrect)
# cjslep[m] That would aid in discoverability of federated peers and of actors on an instance. It doesn't address mentionability though.
# rialtate[m] cjslep: the thing about mentionability is it is a social network, peering social data, meaning, just by exchanging data to operate servers naturally accumulate a lot of peer topology data. Every post that comes in, that is a reply to something else, etc contains actors to discover and once you have grabbed them you have a preferredUsername property to query for mentionability. And as soon as someone is mentioned once by anyone in any post, again
# rialtate[m] just by going about your business processing that you have "discovered". It's quite a bit of a nonproblem IMHO
# cjslep[m] Which is a nonproblem? Discoverability or mentionability?
# nightpool[m] jdormit: yep! I'm one of the main people with a commit bit.
# rialtate[m] cjslep: both
# cjslep[m] @rialtate:matrix.org: Bootstrapping new accounts and instances is a problem though
# fr33domlover Hmmm if my server hosts a project, where would activities be sent (such as open an issue on the project)? To the project itself (which means it has to be an actor with an inbox) or to the user/group managing it?
# jdormit[m] The inbox endpoint can be whatever you want
# fr33domlover jdormit[m], yeah but I'm still asking about whether the project would be an actor you get GET etc.
# fr33domlover More broadly, does the following rule of thumb make sense: Everything that should be possible to follow, should be an actor
# jdormit[m] I think so
# jdormit[m] Otherwise how would you follow it?
# jdormit[m] But you could also just have your users be actors that can be followed individually
# rialtate[m] cjslep: not really though. Thinking about real-world ux, if all a person knows is your twitter handle but not your new fediverse handle they are going to have just as hard a time trying to connect. Conversely if they know your blog is https://coolperson.blog and that is your activitypub endpoint they don't need to know anything else
# fr33domlover Using the "owner" user/group as the recipient also has the problemthat it only works with HTTPS? I mean, in a scenario with distributed storage, you don't care about the project owner, they could even change, and it still remains the same project, it shouldn't make your past activities invalidated etc.
# fr33domlover jdormit[m], yeah I mean if I user has 100 projects and you want to follow just 1 of them
# fr33domlover *if 1 user
# fr33domlover But now I have this issue that webfinger as-is won't work well with the fediverse/mastodon
# jdormit[m] Something I've been playing around with for Pterotype is having wordpress users be actors and have a blog actor Announce individual posts so you can follow the blog as a whole but everything it posts links back to the author
# fr33domlover It's not a critical thing (right now at least), just theorizing for now
# jdormit[m] It sounds like projects should be actors in your model, so you can follow them individually
# cjslep[m] @rialtate:matrix.org: You're not accounting for a general use case that is applicable today: Two people join, one on one instance, one on another. Both are fresh instances. How do they know of and address each other?
# fr33domlover jdormit[m], yeah that's smart I think, like if you wanted to implement a mailing list / forum like thing, you need an actor for the list itself
# fr33domlover in addition for actors for users participating
# cjslep[m] This is the general discoverability problem in ActivityPub. This is why there are federation bots, trying to make up for this problem over time but not being a permanent solution
# rialtate[m] cjslep: not forgetting that usecase at all. They know each other! They talk! Ha!
# jdormit[m] Or I guess you could maintain a followers Collection for each project and deliver project updates from users only to the followers of the project they are posting about
# cjslep[m] @rialtate:matrix.org: How do they know each other?
# cjslep[m] If they're new accounts on new domains that have never sent messages
# cjslep[m] ActivityPub has a zero-state discoverability problem. This is it
# cjslep[m] Sure you can just enumerate every URL in the world and try POSTing an ActivityPub message... but that's not realistic
# rialtate[m] I'm not going to keep discussing why a nonproblem is a nonproblem. A negative can't be proven.
# cjslep[m] OK, I have a real-world test for you: I spun up a new Pleroma instance with a new account for you to message.
# cjslep[m] Please send it a message right now.
# fr33domlover cjslep[m], I've been thinking about implementing world project search possibly using some distributed structure (DHT?) that all instances maintain together
# jdormit[m] It wouldn't be too hard to build a recommendation engine for the AP network
# jdormit[m] You'd need to bootstrap it from known instances, but then it could crawl the network
# fr33domlover And then everyone can find everything
# jdormit[m] fr33domlover: how is that different than the current model where servers send each other their known actors?
# fr33domlover I think for usernames it's a smaller problem, if you're looking for a specific person you likely can grab their fediverse ID URL from their website or ask them in person or whatever
# fr33domlover jdormit[m], idk I haven't examined this send-known-actors think tbh, I don't know how it works, I'd love to know :)
# fr33domlover I guess it's a Mastodon thing? Is it documented somewhere?
# jdormit[m] E.g. Someone creates an account on server A, server A knows about actors on server B and suggests them as people to follow to the new user (or something), the user follows them and now server B knows about the new user too
# jdormit[m] I think the missing step is the "suggest accounts to follow to the new user" thing
# rialtate[m] > <@cjslep:feneas.org> OK, I have a real-world test for you: I spun up a new Pleroma instance with a new account for you to message.
# rialtate[m] Sure, tell me it's address. You don't want to? Then how would I webfinger it or whatever either? Your solution and problem is contrived
# jdormit[m] That would effectively sidestep the need for a global registry, but it doesn't solve the zero-state problem
# jdormit[m] (but as rialtate said above, I don't think the zero-state problem is that big a problem)
# cjslep[m] @rialtate:matrix.org: You just discovered the exact problem I am talking about. I don't believe it is a contrived problem. You can feel free to disagree, and let me waste me energy thinking on this.
# fr33domlover In AFK life, we just meet people, randomly or through other people, this fundamental method works on the fediverse/internet too
# fr33domlover The difference is that you may wish to find like-minded people through shared interests
# cjslep[m] fr33domlover (IRC): I haven't thought about a DHT, since it would need to be failure tolerant as instances (carrying pieces of it) go offline.
# fr33domlover And *that* is harder because stuff like toot tags isn't federated
# cjslep[m] That's why my original suggestion was a simple discovery protocol: a well-known endpoint that has a Service actor that knows of "neighbor" federated instances as well as a Collection of its owned actors.
# fr33domlover In the sense that there's no obvious way to find all the people given a tag; you discover gradually by collecting actors as you go
# fr33domlover (Or browse to a big instance's federated timeline and look there)
# cjslep[m] But, there's probably smarter ways to solve this. I'm sure FreeNet or other P2P things have tackled this. In networking, there's algorithms for building DAGs in distributed routers, for example (prevents too many duplicate entries).
# cjslep[m] Thinking on this more, I think my main problem is that the "zero-state" problem is too big. It consists of both:
# cjslep[m] - Knowing no other federated instances, how to get to know 1 (I agree, not really a big deal)
# cjslep[m] - Knowing of N federated instances, how to get to know N+1 (area I am focusing on atm)
# cjslep[m] Since the second bullet reduces to the former when N==0. There's no reason this should be the case.
# rialtate[m] Not as a solution to anything but just as a useful thing in it's own right, a discoverable "firehose" endpoint would be very useful. Meaning, a way to subscribe to all public posts from a hub.
# cjslep[m] Today you have to introspect all the random links in all the different linked data stuff tossed around by the protocol in a rigorous way to do it right. When it would be much easier for everyone to code if it could skip awaiting user-generated content to do the walk in some sort of different way.
# cjslep[m] And also there's no guarantee knowing N federated peers will have a link to a peer outside the set of N instances. It could be a closed linked data system.
# rialtate[m] Hmm. I hate webfinger, but if you already have it, providing and answer to .well-known/webfinger?resource=https%3a%2f%2fwww.w3.org%2fns%2factivitystreams%23Public seems pretty semantic for the firehose.
# cjslep[m] @rialtate:matrix.org: Sorry that was snappy earlier
# rialtate[m] cjslep: np. I was worried I offended you. I'd prefer if you applied that brilliant mind to more important problems but as you said it's yours to waste 😉
# fr33domlover cjslep[m], DHTs work fine when peers constantly come and go, I think it could apply here. In my use case I want to apply it to projects, it matters more than for users I thimkr users I think, because when you look for software to solve some problem, preferrably you can find them all and the popular ones don't get an advantage over the small ones / ones hosted n small instances. I'd love to have a
# fr33domlover distributed structure where everyone is equally visible with their projects
# fr33domlover It it would be just for projects, not interfering at all with the fediverse's mechanism for discovering human/bot actors
# fr33domlover *It could be jus
# fr33domlover *just
# fr33domlover It's much like, say, bittorrent has discovery of peers via DHT
# rialtate[m] fr33domlover: finding projects even on "small" shared servers (e.g. framagit) can be quite a challenge. I think whole new paradigms will be required to organize and sift through a fediverse worth of projects
# rialtate[m] A project "suggester" algorithm like that used for friends of friends might be good for passive discovery.. Active is a bit more complicated
# fr33domlover rialtate[m], I mean on githu8 it's a single website, it's free to implement any discovery mechanism it wants on its hosted repos. So I'm thinking, I'd like the fediverse to have the same power, to have a global directory of projects where everyone can be found. Idk if a DHT etc. is a significant contribution to that, just theorizing and wondering about this possibility
# fr33domlover (I'm not concerned with this issue at this point, but it will come soon, I suppose)
dmitriz and dmitriz1 joined the channel