kolektiv.xyncro.com
Tech-person, primarily software, occasionally hardware. Somewhat of the left. Dog-dad (also actual child-dad). He/Him. European.
187 posts
63 followers
256 following
Active Commenter
comment in response to
post
We struggle to even define sentience or intelligence, let alone understand it. Nobody honest would claim otherwise, those who do have something to sell.
comment in response to
post
It's also often quite bad at summarisation as well, but people don't notice because they don't check...
comment in response to
post
Just what I've always wanted - a pizza restaurant with a decompression risk and a radiation level that'll cause genetic damage and an early death. But hey, capitalism, right!?
comment in response to
post
Yeah I love this - as if you somehow get good enough at reading and reviewing code without also writing it. If I could tell what a whole program did, accurately, to spec, simply by reading it? Wow!
comment in response to
post
I get the motivation here, but at some point, we need to tackle the motivations behind crimes, not just the instruments. Until then, I'm off to teach youths to sharpen rolled-up copies of the Daily Mail.
comment in response to
post
Surely if the AI is that good, you could also tell it to go funge itself? "Hey Gemini - first task, find me something that's cheaper than you and switch me to it, then cancel yourself".
comment in response to
post
Yay, we're going to try microtransactions again! This year... This will be the year...
comment in response to
post
11/ A return to the early days of the web in some ways, but with so much of what we've learned in the last 30-odd years built in.
comment in response to
post
10/ If we can get there, that could be the start (or rather, rediscovery) of something truly revolutionary - a people-centric web - social, yes, but also decentralised in a way that matters.
comment in response to
post
9/ It becomes infrastructure, like an ISP or a telco, perhaps (ignoring the bad things about those entities for a moment).
comment in response to
post
8/ I'd like (I think) to see an end state where the PDS is a standard (of some kind) with many different providers. If you have one, you can automatically partake in a rich and interoperable ecosystem of apps, whoever your PDS provider is.
comment in response to
post
7/ At some point, we're going to need to work out how to talk about PDS/Identity to consumers (and we need to find a way that a) doesn't use those terms, b) makes the concept of "your own personal data server" understandable and meaningful and c) decouples the concept from bsky).
comment in response to
post
6/ But as the ecosystem goes, this messaging is going to make less sense, and at some point the confusion caused by conflating bsky with "any PDS" is going to become actively harmful to broader adoption patterns.
comment in response to
post
5/ But actually, it's not bsky, but a provider of an atproto PDS that's needed. That's not really a problem right now, bsky is 99% of the ecosystem and all most people are aware of - certainly what they're aware of first.
comment in response to
post
4/ This changes with atproto. The common thing in the system is you and your identity, not any one particular application. Right now we're seeing a variety of new applications built on atproto all advertising "sign in/login with bsky" - and this makes some sense.
comment in response to
post
3/ Social logins have only ever really been a shortcut to initializing credentials - you've still ended up with two separate and discrete accounts if you sign in to one system with another. Those accounts aren't really related beyond that point.
comment in response to
post
2/ One of the promises of atproto is that the consistent things between different systems is the user and their data, and in a less superficial way than we're used to seeing.
comment in response to
post
I've been playing with it, and implementing a few bits and pieces, partly as a learning exercise. I think it's got a lot of potential, so investing a bit of thinking time with it! Pondering building something, not sure what yet but a few ideas floating around...
comment in response to
post
13/ Lack of support for some common patterns of interaction will likely result in less decentralised workarounds in the short term until the protocol supports them.
comment in response to
post
12/ The event model is powerful but potentially increasingly inefficient (some level of notify/push seems likely one day in my view).
comment in response to
post
11/ Time will tell whether that pattern needs augmentation, modification, specialisation, etc.
So, in summary: private things are a (not impossible) challenge but will absolutely require changes/extensions to atproto. Secret things will be even harder.
comment in response to
post
10/ This is kind of OK when the app that's 99% of the ecosystem cares about 99% of the traffic, but will get less efficient over time as the data gets more diverse and more and more apps start caring about small slices of an increasingly heterogeneous stream.
comment in response to
post
9/ Another potential challenge with this architecture is the "firehose" nature of the current event stream. While it's possible to create more focused and tailored streams, at the moment the general pattern is a filtered view on "everything".
comment in response to
post
8/ This means that you can't *send* a message, for example. You could *write* a message in your own data and then hope another user picks it up somehow, but this makes various interaction patterns quite complex compared with other models. I can see this changing one day in some form.
comment in response to
post
7/ The PDS model, where events are generated from changes to user-controlled personal data creates a very elegant architecture in some senses as well, but it also means that one user can't write to another users data (unless the protocol is extended to allow this in some way).
comment in response to
post
6/ Even things like blocks, etc. are only a view-level concern right now - applications may choose not to show you some posts if you've said you don't want to see them, but those posts are *still there*, and the event stream does not differentiate.
comment in response to
post
5/ Remember, the event stream right now contains *everything*.
comment in response to
post
4/ That matters because the usual mode of operation means that anything a "downstream" system wants to know about has to be public too. Hence the difficulty around current discussions of private messages, private accounts, etc.
comment in response to
post
3/ That has various advantages (loose coupling, scales well on some axes, etc.) but also some disadvantages - some of which are being faced now. That kind of event stream usually exists internal to a system but in this case it's all public.
comment in response to
post
2/ As I said in my last thread, this is an event-driven system, with an events -> materialized state model for most of the things that care - generally applications or services supporting applications.
comment in response to
post
Looking forward to reading it! I definitely agree with the risk analysis, and it is going to require something unusual to prioritise long term over short term gains for the Bluesky folks, but I think the potential is worth some time from me, for now at least. I care more for protocols than apps tho!
comment in response to
post
10/ So, summing up: user-owned data, interoperable data across traditionally siloed systems, data and meaning re-use, and a potential story around commercial resilience/proof against enshittening.
comment in response to
post
9/ When done well/safely, the promise of "systems that really understand us contextually" has been something that's been a goal for a long time - the PDS model may offer a meaningful step towards that.
comment in response to
post
8/ A user being a single user across any number of systems (and not just in a "log in with google" way) also has some major implications (positive and negative). On the positive side, there's massive potential for joining people and systems together in ways we haven't so far.
comment in response to
post
7/ Now users own their comments in my application, I can support commenting, and anyone else could do whatever they want with those comments (random example: use "things most commented on across the ecosystem" to create a recommendations system about what's currently most engaging - better examples
comment in response to
post
6/ If I want comments in my app, I could provide a way to write that comment-standard data, and I could listen for that data in the event stream and filter it by people commenting on things that are in my app.
comment in response to
post
5/ If someone else has already come up with a great lexicon for, let's say, comments: I don't need to re-invent that wheel.
comment in response to
post
4/ Obviously this has complex implications for business models, but the user really does own their data, and this introduces what I'd term "commercial resilience". Following on from that, the scheme-based nature of data means that functionality can be shared.
comment in response to
post
3/ If someone decides to start charging for an application, or introducing user-hostile features, another application can compete on that basis. The underlying data is always there, how you see it can change.
comment in response to
post
2/ First of all (and though this may change in future, it's written for an "everything is public" present) it removes the monopoly of any application over content.
comment in response to
post
10/ That combination of things is relatively novel, and I think has a lot of potential (positive and negative).
comment in response to
post
9/ Common types of data can start to be genuinely shared across organisational boundaries. Perfect? No, but an interesting step. So, for me, key things: event-driven, public, interopable, user-controlled.
comment in response to
post
8/ Remembering that all of this data is public, that also means that one application reading data from another is fine and expected. This is one of the big shifts for me - user-controlled data with a story about interoperability and portability.
comment in response to
post
7/ The data is also interesting, as consideration to sharing/interoperability has been baked in quite early with a blessed schema language (Lexicon).
comment in response to
post
6/ So this is a pretty common pattern, except that it's all public, rather than an implementation detail inside a closed system. There are many niceties around identity and content-addressable data in there, but fundamentally, those are quality-of-life additions to the architecture.
comment in response to
post
5/ Applications (AppViews) are what people generally interact with, and they read from that event stream and write back to data stores (sometimes they'll read from data stores).