I don't understand most of the underlying stuff here [1] and I swear, I will one day get to reading the actual (& new and improved) documentation....
- The situation
It seems that data/whtwnd posts are all there and bsky is ignoring it, because it doesn't know how to render them.
If so, it sounds like the current situation is that each atproto app would have to do a case-by-case integration for every 3rd party, which feels like something that would ideally be avoided or mitigated by supporting a solution (full or partial) at a protocol level (e.g. for everyone all at once).
Bridges now because integration is a common problem. Different federated protocols need to bridge to crosspost (nostr, fediverse on ActivityPub, bluesky/whtwnd on atproto), and then there's all the non-federated services with individual integrations and workarounds (like social-media-reposting bots in Discord).
- Cross-posting is a real use case for content creators, born out of the need for audience reach. Integration would solve some of this, at least within the AT protocol.
N-NKSM talks about "pondering and choosing one" platform and using different platforms for different uses ("...post travel photos on Instagram, videos on TikTok or YouTube, and share intolerable events or irrationalities on X"). But there is an additional use case: posting the same content to multiple apps to increase reach. For example, posting the same short video to Tiktok, YouTube shorts, and Instagram stories all at the same time to increase reach, because of a fragmentation of audience.
This is painful enough to warrant monetization. There's currently a variety of paid and free services offering social media management tools for synchronizing or queueing posts across multiple services (although I don't know how effective they are, having not used any myself). For small-time content creators, such services may not be worth the money, so the only other choice is to suffer through cross-posting to multiple platforms. This additional overhead takes away from the time needed to create content, and can be unnecessarily stressful.
This issue also applies to casual posters who've recently moved platforms, away from friends on other platforms, but maybe at a smaller scale. The AT Protocol was built to mitigate the loss of identity and connections, but it only applies within the AT Protocol itself. Since it's still early days, the ability to migrate accounts within AT Protocol is not very relevant to casual users like myself who have nowhere to migrate to (except between whtwnd/bsky). But I have certainly migrated here from elsewhere, and lost most of my connections in the process. If my posts in bluesky don't appear on whtwnd, and my whtwnd posts don't appear on bluesky, then individual apps within the atproto sphere suffer the same problem as apps outside the sphere, except for the fact that my profile-level account information stays. But practically speaking, my audience will be different on each app, unless I manually cross-post, or subscribe to a (currently nonexistant?) automatic cross-poster.
(As an aside: discovery is a major problem right now. Discovery of apps built on top of atproto, for example. And of things within bluesky, like all the things you can technically subscribe to like blocklists and labelers, but I'm having trouble actually finding them to subscribe to. Other places might have megathreads or resource collections to mitigate that, but the microblogging structure of bluesky makes that difficult outside of manually curating and sharing a "feed" of such resources. And then you're always limited to being in the right circle or looking at the right search term, in that case.)
Then there's the viewers' experience outlined in the article [1], and my own personal use case, where I just want everything I subscribe to in one place (or fewer places).
- The concept of an atproto brower (undesired?)
The developer bryan mentions "atproto browser" in this context: "a web browser is a fully general rendering "app". should the bsky app be an atproto browser, or should it be easier to access and interact with atproto content from web browsers?" [2]
Solving it at an app level doesn't solve it everywhere for everyone, which I think is a sentiment expressed by others in the thread too.
But the expression of it being a browser is interesting. I guess the question being tackled here is, where should the solution be placed (and what solution would be best)? If it goes into the protocol, where does it go? And what about partial solutions like providing something in the protocol and letting the app deicde how to handle the info? I guess that's where lexicons are situated right now. The entire network has access to all lexicons, but the app needs to manually decide to parse/handle/integrate the lexicon. And so K-NKSM's proposed solution [3] is additional support in the protocol for rendering, to make rendering available to downstream apps so each app doesn't have to define how to render it.
And then bryan's follow-up [4] is about different app limitations. Like if one app has a complex rendering scheme that doesn't fit on another downsteram app (like richtext on a simple text interface, or long blog posts on a microblogging site).
- The position of social games on social networks
bryan goes on to say "one train of thought I have is that social media design has some similarities with game design. I want developers who are very opinionated about user experience to be able to build stand-alone apps on atproto and have near-total control over the experience, similar to game designers" [5] "a negative example is farmville and zynga on facebook: it changed the experience in a big way, and facebook eventually pulled the rug. to be clear, whtwnd and blogging are positive!" [6]
I quit facebook after I graduated and didn't need to use it for group projects anymore (and thankfully there's better options now), so I'm not too sure what's being referred to here with respect to farmville and zynga. But maybe it was their spam-all-your-friends model of gameplay?
This still exists to some extent, since of course people want to share how their games are going with their friends/audience. And games want their players to share around too. I guess the question is how to filter out the spam, or organize it so it's useful.
I'll take Granblue Fantasy as an example. If you're having trouble with a raid, you used to be able to post it to social media. And there was basically a Twitter scraper service ("raidfinder") that would search Twitter for the specific tweet structure--since it didn't apply hashtags--to pick up and display everyone's raids. It's just that Twitter/X pulled the plug on free/cheap integration so the button to easily post from within the game is gone now, and so the game moved raidfinding internally. But prior to that, I guess the need would be for a way to filter what posts are for what. Within the giant topic of "Granblue Fantasy", there's discussion, images, current events... and raid help, and daily-stamina-refill-spam, all getting posted to the same tag.
The recent roadmap (either for bluesky or for atproto...) talked about better feeds, or better moderation, or better communities, or something like that. I'm hoping it'll include something (like part of a vision) for hierarchical or smart organization of "communities"/discussion topics/etc, but if it doesn't, I guess that's what the federated protocol is for (i.e., time to DIY...).
- Vision
Despite all the drive to get solutions out fast, I think any solution should probably be considered carefully. It really is like (live service) game development: just because players want a specific solution doesn't mean the solution will solve their problem. So then it becomes the game developers' job to identify a solution that they think will solve what they need to solve (and not necessarily what the players think they want solved). That's "vision."
If the game developer can get far ahead enough, then they can start planning a curated experience (shifting meta, planning content arcs, etc.) but that might not apply as much to a social network. The part about users chomping at the bit for content/improvements/development does though (at least until enough are satisfied with the basic experience. Dunno if that'll ever happen).
[1]...A Customer Journey of an atproto User [2]...https://bsky.app/profile/bnewbold.net/post/3krw2m7prru26 [3]...https://bsky.app/profile/knksm5.final-techblog.com/post/3krvmdswiw225 [4]...https://bsky.app/profile/bnewbold.net/post/3krw2j263ep2l [5]...https://bsky.app/profile/bnewbold.net/post/3ksgbftn5ib2r [6]...https://bsky.app/profile/bnewbold.net/post/3ksgbkwdupz2v
