Dream to access and manipulate our data from UI du jour!

[chinarut]

This is a thread to keep our conversation going in regards to a universal datastore - the fulfillment on the idea of a Personal Data Locker (David Siegel) (premium Medium article from 2019 which embeds his 8 min YouTube video) and what I’m noticing some people now call the “ownership economy”

This is all part of a vision we have freedom to choose the optimal UI to view/manipulate our data for the specific task at hand and this changes moment to moment.

Excerpting the discussion from Testing conversation threading in Slack vs. quoting in Discourse:

@Oshyan

One easier route to being able to visualize core data in multiple ways is to simplify to the most basic and flexible primitives.

then society goes off and makes email and texting basic primitives

I noticed two tweets today that made me think there is indeed gold at the other end of the rainbow!

Special request to keep discussion as high level as possible - my intent of sharing these two components is not to do a deep dive but rather to seed the discussion!

1. GitHubNext’s Flat Data project (tweet) leverages the familiarity of a spreadsheet to manipulate/view data

Flat Data eschews the complexity of many tools in the data/ETL space in favor of something simple and flexible enough for many workloads, but which requires no user-maintained infrastructure. While Flat has a ton of utility for developers, we want to make it easier for scientists, journalists, and other developer-adjacent audiences to develop lightweight, data-driven apps.

It never ceases to amaze me what masters get done in spreadsheets - if this brings us a step closer to making it easier to attach workflows to our own data, I’m all in!

2. BlueSky Authenticated Data eXperiment (tweet)

“Bluesky is building a protocol for large-scale distributed social applications. We want public discourse to occur on open infrastructure which gives users a choice in their experience, creators control over their relationships with their audience, and developers freedom to innovate without permission from a platform.”

I believe I’ve shared in another post the platform fatigue I experience not from generating content per se, but from leading/moderating long-tail discussions only to have the platform go belly up, go passe, or just plain abandoned (lack of maintenance or funding) - I feel I’ve experienced it all!

for the record, I do remain skeptic of markdown as a basic primitive (as it is not accessible to people who don’t code or have any concept of code) and aware this is a unifying layer that is text-based and part of Discourse so I’m open

I have to agree, my UN*X plain text files, while I am not actively editing mine, continue to be the most persistent over the decades so it makes sense.

it seems anything in between (eg. HTML) while dominant, still isn’t our chosen “storage” format (again, for good reason!)

ok - hope to be surprised with the advanced “basic” primitives of the future

[Oshyan]

@chinarut

Flat Data eschews the complexity of many tools in the data/ETL space in favor of something simple and flexible enough for many workloads, but which requires no user-maintained infrastructure. While Flat has a ton of utility for developers, we want to make it easier for scientists, journalists, and other developer-adjacent audiences to develop lightweight, data-driven apps.

Yeah, this is very cool! I am seeing something of an interesting revival of the “spreadsheet” lately. There are other examples I could share, if interested. But for now I’ll just say this is definitely interesting and related, and that spreadsheets are a sort of “root data representation”, though not necessarily a root “primitive” per se, depending on how you define it. Interestingly Conor (of Roam) has also said as much in that he sees the huge utility of the spreadsheet model and wanted Roam to become “spreadsheets for text”.

@chinarut

“Bluesky is building a protocol for large-scale distributed social applications. We want public discourse to occur on open infrastructure which gives users a choice in their experience, creators control over their relationships with their audience, and developers freedom to innovate without permission from a platform.”

This is interesting. My very first question was "OK, but what about ActivityPub and other existing protocols and projects in this space? Is this another “Not Invented Here” (NIH), are they trying to re-reinvent the wheel? They address this, fortunately:

Modern social networks rely on a global view of activity to provide search indexes, discovery algorithms, and metrics (such as follower lists and like counts). We sometimes refer to this as “big-world data.” Decentralized alternatives which focus on webs of trust (SSB) or segmented instances (ActivityPub) tend to provide only a subset view of the network (”small-world data”). While an exclusively small-world network can be preferable for some use cases, our goal is to support both small-world and big-world experiences.

The Federated Network provides the substrate for small-world data. We then rely on Crawling Indexers to provide big-world data.

I’m still not 100% clear what their solution does that ActivityPub doesn’t and whether I should be excited, but at least they’re trying to augment existing efforts. Incidentally I’m looking at ActivityPub as a possible protocol for some considerations in the open source dating app discussed here.

@chinarut

for the record, I do remain skeptic of markdown as a basic primitive (as it is not accessible to people who don’t code or have any concept of code) and aware this is a unifying layer that is text-based and part of Discourse so I’m open

There are many possible consequences to what data model/format you choose to use for storage. But I think it’s important to clarify that Markdown is not inherently hostile to “WYSIWYG” or “easy”. Specific implementations are more or less intuitive for “non-coders”, but for example Notion (which arguably is one of the easier, more mass-market TfT/productivity tools of the past 10 years) also supports Markdown. There are many facets to how you present and use a given format, e.g. how it’s edited/created, how it’s viewed, and how it’s saved/stored.

Again Discourse has a little bit of a clunkier model IMO, with preview on the right, “raw” content+formatting on the left. It works, but it’s not immediately intuitive to non-technical people. Obsidian and Typora have a more elegant though still potentially clunky approach of “markdown visible on edit”, where each formatted area only shows the markdown syntax if you click on it to change it. Notion (and Anytype’s) solution is simply to accept markdown for input, but not show existing formatting as markdown, which I think is fine, really.

Speaking of primitives, I think the Block Protocol is touching on some of these issues too:

Block Protocol