Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building on ATProto

lukekanies.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Building on ATProto

#41

Post by verdverm »

MarceColl wrote: post #40
verdverm wrote: post #12

Earlier quoted context omitted.

How do you prevent a player from manipulating game state outside of the app view? There is a subgroup in the Atmo working on games, have you found them yet?

I have a referee server handling that. I haven't! I don't even know what Atmo is, tbh.

"Atmosphere" (atmo) is the self-given name for the broader developer community around atprotocol

https://discourse.atmosphere.community/ has game specific discussions to help you find the people to connect with.

Re: Building on ATProto

#43

Post by XanSurnamehere »

vzaliva wrote: post #25

The intention is good. I like the reviews idea. Since the author has hit the limitations of ATProto, could ActivityPub be an answer?

I doubt it, since you'd own your data even less as a user than with ATProto. (stuck to a server without the ability to fully move backlinks, data, and identity to another. at least all those things stay the same when you move between PDSes!)

Re: Building on ATProto

#44

Post by verdverm »

steve_adams_86 wrote: post #39
inigyou wrote: post #2

What's even the point of publishing anything online any more if you don't hope to become an influencer? The nature of the game has changed, and now does everything possible to discourage it.

You could say the same about publishing offline. We can always do it simply because we enjoy it and one or two others might find some enjoyment or utility in it as well. It doesn't have to matter, it doesn't have to influence anyone. It's fine as a relatively solitary practice like any other.

I've moved off social media to zine making and this couldn't resound more with me these days!

Re: Building on ATProto

#45

Post by fidotron »

verdverm wrote: post #16
fidotron wrote: post #15

Earlier quoted context omitted.

So in your concept if you are A and have two folowers B and C that don't know each other but both comment on your post what should happen? Should you see both but they not see each other? This is the tip of the iceberg of boring questions that fall out, all of which have annoying user experience implications which are intimately tied to the underlying infrastructure and cryptosystems, effectively setting them in ston…

> what should happen? A core principle of ATProto is that the cost of switching is low, thereby facilitating real competition on social media. So the answer is two parts 1. App views decide permission parameters for their modality and frame the user experience 2. Users use these permission parameters to dial in their personal or community experience I believe there is more middle ground than you leave space for. See…

> 1. App views decide permission parameters for their modality and frame the user experience

Yeah, so this is the problem. A system flexible enough for that will be some combination of centralized, hilariously over complicated, massively inefficient, and full of odd unexpected behaviors.

Re: Building on ATProto

#46

Post by jauntywundrkind »

pfraze wrote: post #26

Luke's feedback on the permissioned data proposal is pretty interesting. The current proposal has a kind of locational element to permissions, where a record's URI reflects the access control, and I can understand why that would be jarring. I'm talking with the team about whether we think that's something that could change, and what a change like that would cost. We're still in the collecting feedback phase so it's g…

a meta-note that i think deserves attention: we never ever seen such a level of engagement around a social media protocol as this. count the number of mastodon protocol discussions that have happened, or dispora, or activitypub. they exist as background. matrix maybe comes close if you look at raw count anywhere, but i'd say has no-where near the visibility, doesn't surface/emerge into the public. atproto is succeeding at being a discussed protocol. at being a socialized social media protocol.

and that's just amount of discussion. but what about engagement by the people working on it? nothing like this, not by high level people, discussing in open, talking about protocols. you don't see permissioned data blog serieses coming out about the direction. you don't see the same blogsphere posts. you don't see the CTO coming to chat about it.

a huge amount of this is just that Bluesky people really work hard to do the right thing, are humble and trying hard to build good protocols, good network design, trying to build the most distributable most easy to get the content network out there that works the best. i think also though, the ability of the systems / protocols here to be expressed lends itself to being discussable, has good primitives, that make it fruitful and interesting for things like Permissioned Data, or things like the sync 1.1 protocol, to be generally understandable, good primitives, that are discussable.

luke's points about local first are really good. this is hard challenge for "Authenticated Transfer Protocol", at protocol, which prioritized a sense of identity and data coupling, that is harder to do in local context, that is harder to distribute without the online verification. great concern, great area to focus on. i look forward to more people experimenting with interesting PDS architectures & seeing what if anything might possibly relax to accommodate.

Re: Building on ATProto

#47

Post by Striving7340 »

pfraze wrote: post #27
Striving7340 wrote: post #18

ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed. The difference is that crypto people actually had reasons to run nodes, they got paid to, while ATProto expects enthusiasts to do so for the love of the game or act like bluesky and have 99% of the "decentralized" platform on a centralized node. It never catches on with application developers because it require…

We don't even get paid to be in this cult, that's how organic it is

Apologies if "worship" came across as calling you a cult, but it doesn't seem that you took what I said too seriously either. Good luck on ATProto, certainly don't want to deal with this kind of replies from you or Dan every time criticism or concerns come up, maybe once the protocol leaves BlueSky, but let me guess, it's planned for some point in the far future like every other concern?

Re: Building on ATProto

#48

Post by verdverm »

fidotron wrote: post #45
verdverm wrote: post #16

Earlier quoted context omitted.

> what should happen? A core principle of ATProto is that the cost of switching is low, thereby facilitating real competition on social media. So the answer is two parts 1. App views decide permission parameters for their modality and frame the user experience 2. Users use these permission parameters to dial in their personal or community experience I believe there is more middle ground than you leave space for. See…

> 1. App views decide permission parameters for their modality and frame the user experience Yeah, so this is the problem. A system flexible enough for that will be some combination of centralized, hilariously over complicated, massively inefficient, and full of odd unexpected behaviors.

Perhaps if you are after public square social media. If you are after small social media, the usage patterns and tradeoffs look different.

Modded Minecraft (smp) servers are interesting prior art for me.

Re: Building on ATProto

#49

Post by Karrot_Kream »

verdverm wrote: post #4

This author speaks to me! > it should just be called “private data” > the resulting design looks very hard to build on > Private and public data are basically identical. ... The permission is world-read Way back before Bluesky decided on their own what permissioned data would look like, when the Atmosphere Private Data WG still thought they had a say in the design, I gave a talk on a ReBAC/Zanzibar style system that…

I've followed the ATProto space (and seen you around the space) a bunch over time, and honestly for the private data portion of it, I'm quite bearish on the idea of an ATProto shaped thing winning here.

I do think "small social" is winning in almost every definition of the word. There's Discords for everything, each non-technical person I know is in 10s of group chats, folks on Instagram or Twitter seek their "communities" on these apps. HN and Reddit are somewhat platforms of yesterday, valuable only for the sheer volume of conversation, not really of any particular use, often used to doomscroll on the toilet or in the supermarket line.

But ultimately I don't see why you need a protocol for small social. ActivityPub could do it fine (even though it's largely used as a glorified JSON HTTP API), Matrix or IRCv3 can do it fine, email works and is being used, heck you could even roll a bespoke HTTP or Websocket RPC (de-facto ActivityPub) to fix the problem anyway. ATProto is useful because it's a protocol for socializing In the Large. I think user experience matters for this much more than a protocol. I know Bluesky users want it, but I'm not convinced that an ATProto derived solution is the answer.

Re: Building on ATProto

#50

Post by verdverm »

Karrot_Kream wrote: post #49
verdverm wrote: post #4

This author speaks to me! > it should just be called “private data” > the resulting design looks very hard to build on > Private and public data are basically identical. ... The permission is world-read Way back before Bluesky decided on their own what permissioned data would look like, when the Atmosphere Private Data WG still thought they had a say in the design, I gave a talk on a ReBAC/Zanzibar style system that…

I've followed the ATProto space (and seen you around the space) a bunch over time, and honestly for the private data portion of it, I'm quite bearish on the idea of an ATProto shaped thing winning here. I do think "small social" is winning in almost every definition of the word. There's Discords for everything, each non-technical person I know is in 10s of group chats, folks on Instagram or Twitter seek their "commun…

strong agreement here

> Ultimately I don't see why you need a protocol for small social.

For me, it is less about the technical reasons and more about the movement away from corporate control to community ownership. The desire among people is there because the growing shared belief that what we have today is not healthy for our self or society.

One thing Bluesky nailed was simplicity for the average user. UX is super important. That was despite the protocol which almost all users, and non-users who've heard of Bluesky, have no idea about. However, it was the protocol movement that formed the foundation for their success.

That being said, you can only realize the vision (of the people taking back social media from the capitalists and enabling real competition in social media) with a well designed protocol. ATProto gave us a lot towards this. So I'm now contradicting(?) my first sentence in this comment.

Post reply on HN