Live data from Hacker News

A Social Filesystem

overreacted.io

221–230 of 243 posts

Re: A Social Filesystem

#221
post #61
post #26

Earlier quoted context omitted.

>helping build a perfect decentralized surveillance record a record of what? Posts I wish to share with the public anyway?

It's not about the access, it's about the completeness. Imagine this paradigm takes off (I hope it does!), everyone has their own PDS and finally owns their data. Social apps link into their PDS to publish and share data exactly as they're supposed to. Well now someone's PDS is a truly complete record of their social activity neatly organized for anyone that's interested. It's not a security issue, after all the data…

The completeness AND the reliability!

Consider that a muddy, "oh a bunch of different servers downloaded this guys history, but it's different on one from the other" could be ORDERS OF MAGNITUDE SAFER from a surveillance perspective.

Re: A Social Filesystem

#222
post #31

Earlier quoted context omitted.

This seems like tensions between normal/practical and “opsec” style privacy thinking… Really, we can never be sure anything that gets posted on the internet won’t be captured by somebody outside our control. So, if we want to be full paranoid, we should act like it will be. But practically lots of people have spent a long time posting their opinions carelessly on the internet. Just protected by the fact that nobody r…

Exactly. Anything that's ever been public on the internet is never really gone anyways, and it's unsafe to assume so. This is similar to publishing a website or a blog post. Plus, from a practical (non-opsec) point of view, you can delete items (posts, likes, reposts, etc.) on ATProto, and those items will disappear from whatever ATProto app you are using - usually even live. You need to dive into the protocol layer…

Your first statement is good advice, but is factually WRONG. Stuff does go away.

We know this from the other side of it, stuff that we WANTED to keep, but couldn't. Google deleting blogs, people not maintaining their own personal media records, etc.

Now. What is a good forward GIVEN THAT we do know that stuff CAN go away? My gut is that a good balance of "making personal stuff available to people who want to see it again" vs. "surveillance state" could make use of the unreliability of "the net." And that ATProto's "perfection" isn't all that helpful.

Re: A Social Filesystem

#223

Earlier quoted context omitted.

That's a great question! Adding new features is usually not a problem because you can always add optional fields and extend open unions. So, you just change `media: Link | Picture | unknown` to `media: Link | Picture | Video | unknown`. You can't remove things true, so records do get some deprecated fields. Re: updating safely, the rule is that you can't change which records it would consider valid after it gets used…

That's true if you define the problem as "does my parser crash" and not whether the app is perceived as working correctly. If some platform adds support for video posts, then the next thing that happens is people start making posts that are only video. Meaning that in every other client, users see what appears to be an entirely empty post. Which will be considered a bug. This is the core argument of Moxie's seminal e…

I disagree that Bluesky is in conflict with The Ecosystem Is Moving. In contrast to most decentralized/distributed protocol projects they've managed to maintain control of almost all of their infrastructure with the exception of the personal data servers (pdses) of which they control 99.01%[1]

Almost all ATProto apps just fetch posts by handle => did:plc => post-type aka "lexicon", so they depend on what Bluesky decides to give them. If someone were to introduce unknowns into the flagship product's "lexicon" they could fix that at the API or Indexing level before shipping this data to the apps that depend on their API.

An actually decentralized network would have to overcome Moxie's criticism of the ecosystem. Can it be done? We'll keep trying.

[1] https://arewedecentralizedyet.online/

Re: A Social Filesystem

#224
post #95

Earlier quoted context omitted.

The data is not transferring, but the user is. When I sign up for e.g. Twitter, I don't want to sign up for Mastodon, or Bluesky, or Truth Social, or whatever other platform someone might create later. Thus I would not choose to put my data in a PDS. I feel like that would actually leave me with less ownership and control than I have now. My point is that I don't believe the separation of frontend and data is desirab…

Do I understand correctly that your main concern is that some random service would serve a page when asked for /your-handle, and so, given a link, someone may assume that you actively use that service? Just trying to understand the exact scenario. Generally it's good practice for AT apps to treat you as not signed up if you have not explicitly signed up to this app before. So I think a well-behaved site you never use…

It's kind of just like, this sense of the "safety" of the walled garden (which one might argue the overlords could rugpull at any moment, which kind of happened with Twitter, but that's not something that really concerns me personally enough to trade it for the complexity of decentralization).

A lot of it is presentation. Instagram is the one that I use the most right now, and I feel like they really nailed this in the "everybody can make content" era. When I'm creating content for IG, I know exactly how it's going to look, there's editing and previewing tools, there's a confidence that people are going to receive it in the manner I intended and expected, and it's tied to the culture of that platform that I've become attuned to over time. The thought of a JSON of my IG post existing in a clearinghouse that encourages people to remix it into whatever, just kind of gives me the ick. Even if realistically it wouldn't really be abused, I don't feel compelled to choose that. If someone comes up with a new app that does some things better, I can choose to migrate to that, but likely I wouldn't want to just one-click import my IG history. It will be different in some way and I would want to make new content for it.

I guess I just kind of see these platforms as bespoke communities that people choose to be a part of, more than fungible data frontends. It's very personal, and...social. It's not the abstract world of data that programmers live in. My social graph in each app is unique and I don't really want it abstracted to one monolith that follows me everywhere. Each one is a new world with a fresh start.

Now, the IG post ecosystem is a lot more complex than it is with Twitter. With Twitter being at its core just text, it lends itself better to different views, but still, formatting matters and there are really a lot of rendering decisions to be made in a modern Twitter client. And again it just seems weird to me to have this oddly fragmented community with unavoidably complex interop semantics rather than everyone just being under the same roof. User opt-in aside, they will all develop their own features and quirks and they and the users will have to navigate how those translate or don't. Twitter clients are/were at least unified by the Twitter API. Regarding your initial question - it's more than just the profile page, do my comments show up in conversations? Likes and follower counts? Or are there weird gaps and discrepancies everywhere from users that haven't opted in? What if one fork requires mutual "connections" and one uses one-way followers? Each platform will make their own decisions. It just sounds like such a mess, and people will spend so much time disambiguating (oh no I'm on this one so I see it that way...).

There were some efforts to fork Reddit but it has survived as a great example of how lots of different people with different interests and opinions can occupy different parts of the same platform, even if lots of them complain about it because it's not their perfect vision of what it should be (see programming languages, and pretty much everything that reaches a certain userbase).

Re: A Social Filesystem

#225

Earlier quoted context omitted.

> the expressed preference Marketing and culture can do wonders to one's preference. > synonym for capability Yes and no. An "app" is usually a set of capabilities, not a single capability. Many of the core *nix utilities for example are specifically designed to have a single capability each, and these are then composed for complex requirements. But for the most part today's apps contain multiple, usually overlapping…

FWIW the Look Up feature, whilst built in to macOS, can also be implemented using "services" which are a way to plug in to other apps and system features like text rendering and highlighting. I can also select text in your message, right click, services -> "Add to music as spoken track". That's a plugin offered by an app. It's only one extra click. My perspective on why OpenDoc/OLE failed are different to yours. The…

> implemented using "services"

Yes that's a pattern offered and used on all modern OSes to various degrees, but most - particularly independent - developers prefer to bundle the capabilities they're offering in such a way that they're only available via their app's interface. I think partly because it's just easier to implement that way, but also because it's in their interest (not the users') to not allow the capabilities they've implemented to be accessed by apps created by others.

> perspective on why OpenDoc/OLE failed

It's not my perspective at all; that's what's in the Wikipedia articles, which I linked. OLE had more success because Microsoft was far more invested in it, since it was theirs, and is still used today in Windows (sounds like you're saying it's dead); OpenDoc was an attempt at an open standard, and failed because the participants just weren't invested and/or agreeable enough. Of course I can see Jobs driving the final nail because, for him, it wasn't exactly in Apple's best interest to create apps that interoperated with apps outside the Apple ecosystem. All those are people/policy things.

> rendered irrelevant by the web

I don't really get what you're saying here, in the context of capability provision. But I'd say no. There are many web platforms offering capabilities via APIs, but still many restrict access to their own apps, with Reddit being one of the latest to drastically restrict 3rd party access.

Re: A Social Filesystem

#226
Makes me think of Syncthing... I wrote a wrapper for it that attempts to make it easier for people to use:

https://github.com/chapmanjacobd/syncweb-py

https://github.com/chapmanjacobd/syncweb-ui

Unfortunately, mesh storage systems are very different conceptually so it is difficult for people to think about permissions and access. You can bolt on something familiar but then it really limits the usefulness of mesh storage and you may as well just be using HTTP servers.

Re: A Social Filesystem

#227
post #213
post #207

Earlier quoted context omitted.

I never managed to get into mastodon because mastodon isn't a single space. It's a bunch of separate, linked spaces. Which server you're on matters a lot, and I never found one that really had the vibe I was looking for. Bluesky, though, is one big pool. There's no seam between servers. The experience is much nicer. Also, bluesky caught on among my peers in a way that mastodon never did, which was always going to be…

> There's no seam between servers. This is false, if we're to believe it's possible to exist outside the moderation control of Bluesky corp. It's also false today while everyone is still on the same "instance" - e.g. ICE joining Bluesky and being verified is making waves... apparently being _that_ is not enough to violate Big Blue's community guidelines.

If you run a separate appview, bluesky can't censor your interactions in any way, and you can seamlessly view posts from both bluesky users and users banned on bluesky.

Of course, running an appview that indexes the whole world is expensive, and running an appview that doesn't index the whole world is less convenient than just using bluesky's appview, so the only people running an independent appview right now are blacksky.community. It isn't stable yet, but it works, and there are active users who are banned on bluesky: https://staging.blacksky.community/profile/did:plc:63hvnyjvq....

I'm optimistic that running independent appviews (especially appviews that index content lazily, on demand) will get easier in future.

Re: A Social Filesystem

#228
Is there a community or forum where questions about ATProtocol can be asked?

Can you can spread your identity across multiple PDS repositories? Was thinking about creating a PDS that can store binary blobs to download, but not all PDS would like that amount of binary data stored.

UPDATE: found it: https://discourse.atprotocol.community

Re: A Social Filesystem

#229

Earlier quoted context omitted.

what would you do about the at-uri?

at://hash at://pub i guess I don't know why we need at:// that seems like something we'd need in Beaker Browser. After reading the docs at https://atproto.com/specs/at-uri-scheme and building applications that integrate with the Bluesky API, it’s clear why this format is useful for interacting with their system. For developers working outside the ATMosphere, however, it may feel less familiar compared to more convent…

Well, when you figure out why at:// exists and why your hand waving away it's role in your "I guess" makes it impossible... we can chat then

Until then, you are just slopping about like an ai

Re: A Social Filesystem

#230
post #134

Earlier quoted context omitted.

What’s the plan for this? Sharing with a specific group (DM, group chat, feeds from people you follow) are critical to social media.

See https://www.pfrazee.com/leaflets/3lzhui2zbxk2b for some recent thoughts from a team member.

Bnewbold's comment on GitHub is still the best resource. It's far more specific in scope and details. Paul's note is more theoretical / philosophical
Post reply on HN