thoughts about reusing fyi.unravel.frontpage.post lexicon?

[codegod100]

I've been contemplating creating a bookmarking tool and was wondering about using fyi.unravel.frontpage.post to store the bookmarks.

I think one of benefits of the atproto is that applications can share lexicons and not have their data siloed into one lexicon/per app, which is essentially a walled garden.

[tom-sherman]

We currently consider the lexicon in an alpha state, which for us basically means we're probably going to make breaking changes to it soon 😅

This makes it not an ideal target to develop against right now but there's nothing technically stopping you of course!

Aside from the lexicon being unstable, there are some things specific to your use case to consider.

• Frontpage currently had a single global feed and we have relatively low activity. Consider how creating lots of your own posts may discourage others from participating (this is mostly on us to fix with eg. Feeds and communities, but thought I'd call it out!)
• With the future introduction of communities we'll be encouraging the idea of moderating off-topic content
• We're considering allowing community moderators to curate posts by eg. Editing titles, merging duplicate posts
• We are thinking about rate limits in the AppView. Globally and per community.

Non exhaustive list as Frontpage is still very young and we're still figuring this stuff out ourselves!

[codegod100]

Consider how creating lots of your own posts may discourage others from participating (this is mostly on us to fix with eg. Feeds and communities, but thought I'd call it out!)

With the future introduction of communities we'll be encouraging the idea of moderating off-topic content

One thing I've been thinking a lot about lately on atproto is data sovereignty. The oldworld model is that an app essentially owns the user's data.

In the atproto world, it very much feels like this relationship is inverted and the apps are merely consumers of my data. I post data to my repo, and then some external system reads my data and syndicates it outward.

I am weary that atproto application developers will be entrenched in their thinking that my data is in fact their data and put restraints on my behavior when dealing with my data.

I understand your current considerations for your user experience, but if I have to think about how my data effects your platform then that is a bit of a smell for me.

I'm trying not to be too critical of your software as I really enjoy it. I'm merely pointing out some waters that I foresee have the potential to be dangerous and since you're one of the first apps on this platform I'm putting my musing here. Please don't take my critiques as any kind of attack.

[tom-sherman]

I am weary that atproto application developers will be entrenched in their thinking that my data is in fact their data and put restraints on my behavior when dealing with my data.

On the contrary, this is why we're here and not building a centralised app. However what I believe you're referring to is not actually decentralisation of data but decentralisation (and federation) of experiences.

The way we're thinking about it is that Frontpage, the global feed that currently exists in the app, is a feed owned and operated by the Frontpage team just as the Discover feed on Bluesky is owned by the Bluesky team. As owners of that feed we get to set the vibe of that place.

A layer behind that is obviously driven by the decentralised data of atproto (you own it in your own PDS).

We plan to add decentralised and federated aspects of the experience in two ways: Communities and Feeds. (Maybe there are others but those are the two on the roadmap right now)

Not to get too philosophical about it but this blend of data ownership and centralisation of experience is something that I really appreciate about atproto and have posted about before. If we wanted to build a centralised app then we would have just done that, but we believe the new and pragmatic decentralised ecosystem of atproto is the future of building public social media so here we are!

[codegod100]

The way we're thinking about it is that Frontpage, the global feed that currently exists in the app, is a feed owned and operated by the Frontpage team just as the Discover feed on Bluesky is owned by the Bluesky team. As owners of that feed we get to set the vibe of that place.

This is what I'm trying to get at. I think that the actor who controls the domain should only control the shape of that schema and nothing else. I don't think of it as individual feeds. I view it as one feed with actors that filter that feed based on schema shape. Currently it's being treated as separate feeds which are controlled by separate fiefdoms and this is something I caution against because there is this implied ownership over that data I put in that collection. I think this is not good.

If actors assume ownership of the "feed" that is the data stored in the collection, I feel like it impinges on the sovereignty of the repo owner who is the one who actually owns that data.