Discussion: Common social network features

[roxaloxa]

I thought it'd be interesting to have a place to talk about common social network features, what they mean for Rotonde, and how they'd even be possible in this environment.

For example, there's a list of the portals you are following. What about a list of portals following you? That's great for discovery and understanding your social circle, but how does that kind of reverse look-up happen in this distributed environment?

[neauoire]

There is no reverse lookup at the moment, or notification from unfollowed portals. I'm kind of on the fence on this, it wouldn't be too hard to implement, but at the same time we open the door to abuse and the need for moderation tools.

[roxaloxa]

Well, where do you see Rotonde going? Maybe it's worth it to start figuring out what can be done against abuse and make it foundational to the platform.

[neauoire]

I like non-intrusive discussion. I would love it if the public conversation/notification loop only existed around #hashtag starting entries.

[sknebel]

There is no reverse lookup at the moment, or notification from unfollowed portals. I'm kind of on the fence on this, it wouldn't be too hard to implement

How would you implement a "who's following me" lookup here? I might be missing some feature of dat, but I can't think of an easy way to send a notification about this to a dat?

[ianh]

Personally, I like not having a list of who's following me. It's too easy to get stressed about follower counts on Twitter.

[pfrazee]

I've got some thoughts on solutions for this, plus a few things I want to mention.

about tooling

We're developing some higher level APIs to help with this kind of work. The first is IngestDB, which abstracts over the filesystem. It stores data as files in Dats, but adds indexing so you can run queries like listPosts(). Take a look at beaker-profiles-api to see what kind of stuff it can do. It's what we use in beaker's 0.8 dev branch.

You can run an Ingest inside your application, but we'll also have a builtin Ingest with some fixed data definitions and queries in Beaker 0.8 (we're calling it 'webdb' atm). Our meta goal is to provide different abstraction levels that trade control for convenience. In Rotonde, you're using files directly, which is the lowest-level abstraction with the most control. You can bring in Ingest if you want a little more convenience, and then webdb is the push-button solution that's least customizable.

One advantage of using webdb (or its semantics & structure) is that you'll be compatible with other applications that follow its schema. But that's a choice ya'll can make for your project. There's just tradeoffs involved and I want to make sure I'm explaining them.

about reverse lookup

About reverse lookup, I wrote about that topic here. The gist of the post is, Dat is a pull network, and so the purely p2p version won't give you information you don't pull (aka notifications about users you dont follow). Here are the options I'm aware of:

• Do nothing. Just show data from people you explicitly follow.
• P2P push messaging. A p2p push system is not infeasible, but it has two downsides: it requires mutual uptime between nodes, and spam. It would need work in Beaker core.
• FOAF expansion. When you pull data, read the people your follows follow, and read them too. This is what SSB does. It's not perfect but it's not bad either.
• Crawler / aggregator services. Run a service that crawls the dat network and looks for information you might care about, then puts it in an inbox (or other kinds of views).

I'm an advocate for the crawler service solution (that's what my post is about). The reason I like it is, the services are extremely customizable in userland, unlike for instance a p2p push messaging network, which needs to put rules to fight spam in the protocol. Crawler services also dont have a data-silo problem because they're just reading from the open network.

At some point, we'll put a configuration registry into Beaker so that users can choose services (such as a crawler) and then apps can ask for which service to use.

[neauoire]

@ianh I'm the same, it feels healthier not to run after this sort of ticking number. It inevitably forms biases over people. We could remain an entirely organically formed neighbourhood, where we only know the happenings of our immediate network.

I've been thinking about a sort of "discovery" feed, where we could crawl for 2nd and 3rd level portals, so you portals' portals and their portals. It might be a good place to visit when looking for gradual expansion of your own network.

[roxaloxa]

@neauoire @ianh that's a really interesting way of looking at it.

I wonder if what Rotonde needs is a sort of manifesto to better understand what a feature roadmap actually looks like. It's so easy to be like "well Twitter has X, so Rotonde needs it too" but obviously that's a bad path to go down blindfolded.

[neauoire]

That might be worth it, code-wise, I like that we're not relying on external frontend libraries, that avatars are forced vectors, I think this inspires experimentation and creativity(and animated avatars!!). I think we should limit the portals number to 150 to keep it under Dunbar's Number, going over this dehumanizes the network.

[neauoire]

@sknebel no you're right, looking into it deeper, it turns out I overlooked a few things, especially now that we're reaching people with 50-60 portals and crashing, my idea would NOT have scaled too well.

[lsjroberts]

@pfrazee Interesting stuff.

The only downside with a crawler is that you in a way lose control of your own data right? The crawler takes it and stores it in it's own database. Personally, I'm not too worried about that for my own data, but it feels a little like it might run counter to some of the user's expectations. Unless it was limited to just posts with hashtags for example. Or even provide the user with opt-in/opt-out.

FOAF expansion / discover feed is definitely something that would be worthwhile though.

I would be very much onboard with using the 'webdb' api. Because in reality instagram, twitter and facebook are nothing more than different views onto the same data. And it'd be nice to be able to share as much or as little data as you like and each view can take advantage of each bit of data. Largely what is talked about on the wiki with profiles I guess.

[neauoire]

@lsjroberts Likewise for the webDB API, but if I understood correctly, it's not out yet, but will be included in 0.8

[pfrazee]

The only downside with a crawler is that you in a way lose control of your own data right?

@lsjroberts The crawler should just be copying your data and putting it in a view. But, the person who runs the crawler will set the rules for what goes in the view, so, there is that. Foaf or a discovery feed are both good options too.

@neauoire correct, we'll try to get a pre-release in yalls hands before december

[roxaloxa]

I understand the argument against seeing who follows you, but I feel there is currently a very undesirable problem where we are encouraging conversations with things like @ mentions but there is zero way to actually see them if the follow isn't mutual. Even with the FOAF/discovery feed, if a new person who is entirely disconnected from any existing social circle tries to join in a conversation, they're left out.

[lsjroberts]

For reference, aeon made a FOAF thing here dat://7916f98af2cb7f6247fe8c234af0ab3134f8a8f61ccb09648d1c7e30db1db03b/