A Customer Journey of an atproto User

@knksm5.final-techblog.com

I am a developer who wants to create a content platform.
I am thinking about how to energize my platform.
First, I decided to think about what my target users are thinking and how they can contribute.

What do content creators think?

There are two types of users on a content platform: those who create content and those who view it.
Let's start by considering the content creators.

Why do people who post content, articles, drawings, or videos on social media do so, and what criteria do they use to choose their platform?
Why post travel photos on Instagram, videos on TikTok or YouTube, and share intolerable events or irrationalities on X? As far as I can think, the motivations for creating content and sharing it with the world, in order of what I believe to be the most common, are:

  1. Wanting to be praised or empathized with. Many people, including celebrities I like, to see it and receive lots of praise and affirmation. Deep down, hoping to become famous unexpectedly, to be respected by classmates, scouted by an entertainment agency, and possibly date or marry a handsome actor or a member of an idol group.
  2. Wanting to earn money. Being known by many people and getting paid for content, gaining supporters who pay regularly, or receiving donations. Creating promotional videos to sell products.
  3. Wanting to assert personal opinions, move many people's hearts, and change the world.
  4. Wanting to showcase skills or knowledge and provide evidence of capabilities through likes and shares by many.

These are likely motivations, and naturally, the choice of platform would be based on these motivations. In other words, platforms that:

  1. Are likely to be used by many people and are easy to gain empathy. Everyone in the class uses it, and celebrities also watch it. Each platform has its appropriate times, places, and occasions, hence people choose accordingly.
  2. Make it easy to earn money. Meaning platforms where content can be easily seen by many people and can be sold or subscribed to.
  3. Provide the opportunity to change people's opinions.
  4. Receive many likes.

Once these fundamental needs are met, then one might consider posting content just like that famous person they know.

  1. Whether the user base of the platform will accept and spread the content one intends to post.
  2. Whether the site design displays their creations beautifully.
  3. Whether the platform's policies prevent account bans, deletion of created content, or making them invisible.

Comparing these factors, pondering and choosing one to compete in the most advantageous place seems logical.
The issues of content being removed or monetization methods being changed are considered only after the basics like dissemination power and monetization systems are fulfilled, and they are the least prioritized aspects in this context. Fundamentally, platform providers will also strive to limit developments that do not contribute to dissemination power or monetization.

"People shouldn't only seek praise or assessment from others in life, it's enough to value those who truly appreciate your worth. While making money is necessary, why not create content based on what you 'like' and consider it a bonus if it earns money? Constantly aiming for evaluation can be exhausting." This opinion has always existed and seems valid. However, how many people can actually abandon the worldly desires of being praised or becoming famous and escape from the suffering of this world, and can this be said to those who make a living from it? Unless an alternative is proposed, acceptance seems unlikely. After all, the chance to connect with that small group of people is determined by the number of platform users, dissemination power, and recommendation capabilities, supporting the idea that user population should be increased.

What do content viewers think?

How do content viewers choose platforms and create accounts?

  • They want to catch up with people they find interesting or get interesting information as quickly as possible without missing any posts.
  • They want to support people they like on platforms where those people are present.

That's probably the case.
If interesting content is available, people will watch it regardless of poor UX on the site, for example, the amount of advertising on YouTube is increasing, but there hasn't been a significant increase in people who stop watching videos because of it.

A Developer's Story

The obvious conclusion is to increase the number of people who bring in interesting content, and to strengthen the user population, dissemination power, and monetization systems.
As a service developer, I would like to say, "My service meets the minimum requirements for user population, dissemination power, and monetization system. So, please look at this interesting feature that has never been seen before."
If I were to be greedy, "My service exceeds other platforms in terms of user population and dissemination power, and also has a monetization system. Plus, it has interesting features and a beautiful UI."1

I would never think of creating something decentralized.

While browsing X with these thoughts, I wished there was a clean version of X without unwanted posts or annoying bots.
Then I heard about Bluesky, which seemed like the good old days of X, and moreover, Bluesky uses something called the atproto protocol as a demonstration and reference implementation.
As an engineer, I was intrigued and at the same time felt hopeful that I might be able to use it for my service.
When I opened the atproto site, it was full of technical jargon I didn't understand, first overwhelmed by terms like PDS, DID, lexicon, xrpc, DAG-CBOR, CID.
However, this only accelerated the mysterious atmosphere, increasing my expectations for atproto.
I struggled to read the content on the site, read between the lines, and understand while sometimes reading papers on Merkle Search Trees or looking at actual code on GitHub.
As I gained understanding, I realized that atproto was designed for creating "decentralized" services that could cooperate with each other to share and exchange content.
Perhaps, if my service joined the network, it might increase its reach and initially have a large population, which might appeal to content creators.
However, it is also true that as I researched, I wondered why no other service using this protocol had emerged besides Bluesky, and I couldn't form a concrete image of what interesting things could be done using the protocol.
Creating a service takes time and effort, but I resolved to explore the true value of atproto by using my private time to create a usable service with atproto.

Through trial and error, I managed to use it and launched a blog posting service completely different from Bluesky.
I announced my service on Bluesky.
Perhaps because many people had the same idea, I received a fair response as it was a separate product using the same technology as Bluesky that no one else had made before.
However, I was not satisfied with my service.
Because, despite my service being on par with Bluesky, it was treated like any other website on Bluesky's UI, and I did not receive any of the expected benefits of dissemination power or user population.
It looked no different from existing services on Bluesky, so I could say that atproto did not contribute to enhancing the competitiveness of my service.
Users could switch their service to another similar one anytime thanks to atproto, but since there are no such services, the benefit is virtually none.
Some people liked the service I created, which was a pleasant surprise.
However, on Bluesky, when people say, "Where are the atproto third-party services? I want to see them now!" those who liked it would introduce my service, but the majority's response was indifferent.
"It doesn't make sense because I don't understand the greatness of atproto, show me something more solid," "Yes, maybe it's using atproto, okay, next."
Despite feeling frustrated, I had no words to retort, and that was the reality.
My service's data should be reaching Bluesky, but Bluesky doesn't understand it and simply discards it.
It's true that I can improve the quality of the service by for example making the UI more beautiful, without relying on atproto.
But if it is the only way, what is the point of using atproto in the first place?
This situation is unlikely to change even if other services increase.
They also do not have the time or obligation to cater to data from services that do not have power.

At this time, a roadmap regarding the future of atproto from the Bluesky team was released2.
Knowing that atproto is still incomplete, I opened the page with high hopes.
As I scrolled, my expectation turned to disappointment.
They will improve the authentication system, increase the number of Firehose events, etc., certainly the bare minimum, but I saw no measures to strengthen the collaboration between atproto services, which I feel is the biggest issue.
Ah, in the end, my service will continue to be ignored by others, I intuitively felt.

Bad End Path

Gradually, I no longer understood why I was using my precious private time.
I was nowhere to be found, the person who was excited about witnessing a moment when new technology could change the world.
Eventually, my efforts to improve the service stopped, and a few months later, confirming that there were no users left, I quietly announced the service's closure.

Happy Ending Path

While choosing my words carefully, I posted my frustrations with atproto on Bluesky.
Coincidentally, one of the developers of Bluesky/atproto saw this and reached out to me, asking, "How would you like us to display your service's data, and how would you not?"
Thinking this was my last chance to address the frustrations, I began writing feedback using the service I was developing.

"First, please make it immediately obvious that the data from other services is different from that of the average website."

"I would be disappointed if my record looked just like any other website even though I created a service using atproto, And currently, that is indeed the case.

I'm not asking you to write the code to render my service's data.
I know well how my service's data should be rendered.
Please create a mechanism that can resolve the method of data rendering.

If your service or its users do not want certain services, they should have the right to mute or block them, so it's better not to make other people's lexicon display mandatory on the protocol.
Also, if you dislike the original lexicon creator's rendering but still want it displayed, you should be allowed to override the display method.
Furthermore, if a third party other than the NSID holder creates a renderer, the users should have the freedom to switch to it.
You probably want to maintain a sense of uniformity in your own service.
You wouldn't want to display unlimited data in the same way as other posts in media that is designed around character limits.
When resolving this, it would be nice that you could provide context such as dark/light mode, screen size, whether there are character limits, whether the display occurs on a timeline, in a notification area, within long-form text, within a video, within a photo, on a browser, or on a CLI, and strive for the best way to adapt it to your service.

I don't ask for technical details. Whether it operates in an iframe, or you create a styling description language, I think there are ways to do this.

I leave it to you as I think it's a trade-off with protocol complexity, but stock answer is tough.

"Not only the display, but please realize interactive features that can only be done with atproto. By doing so, content creators, if they wish, can get more reactions from many people within atproto and feel motivated to create more content."

"Please make it easy to send comments, likes, etc., from any service.
For example, right now we are giving special treatment to Bluesky by creating a 'Post reaction on Bluesky' form.
Please enable the same UX for any Lexicon without hardcoding on our side.
Existing websites like blogs are arbitrarily selecting share buttons for Facebook, Instagram, X, Hatena Bookmark, etc.
If my service is always included, it increases the chances that users will write reactions using that service, which is a major benefit of using atproto from a developer's perspective.

If you create something here, all the atproto users are your audience and you can get reactions from every corner of atproto, and each one of those can give you a sense of accomplishment, allowing you to see reactions from unexpected services and connect with an unexpected audience. Please let us say this.
Let the records themselves speak for what kind of UI and what kind of record will be created, or make it resolvable.
Depending on the lexicon designer, it should be possible to create full content on other people's apps or only send small reactions but restrict full content to our site.
From the platform provider's perspective, even if reactions are created in another app, it benefits content creators, so it is advantageous.
Also, by enabling our main content to be created on Bluesky, the data is shared, so our platform's content ultimately becomes richer, which should be seen as a plus.

"Please allow content creators to display any proud, confident work they've created on atproto services on their profiles."

"For example, a video creator would have a video playback box, a writer would have a 'Read more' box that expands or transitions to another page, and game streamers would have proofs of records or certificates received from game servers. Since we're sharing the same identity, it should be possible to view it on any service.
This would make your work more visible, connect you with people with similar interests, and increase the chances of receiving reactions.
It doesn't make sense or is odd as long as the profile is a bsky lexicon.
Please treat the profile as a first-class citizen on the protocol, or further abstract it, or create an upper layer."

"Please ensure that you do not overlook interesting things being done by interesting people on atproto."

"Why do people register for a service?
To quickly know about interesting things being done by interesting people, enjoy them, react, and support them.
If atproto can stream all data from all services via relay, then you can create a mechanism that allows you to not miss interesting people no matter what service they use, without having to create individual accounts for each service.
This lowers the threshold for visiting services to check them, making it easy for users and increasing the likelihood of content creators being seen, and it's also a pleasure for service providers.
Of course, just showing JSON won't make sense to users, so please display it richly.
It might be fine to stream other services' activities on the Bluesky timeline, but since there theoretically could be atproto users who don't use Bluesky, it might be better to create a separate atproto browser for that.
I think users have their favorite services, so if possible, let them check without leaving their favorite service, and if they want to see more details, then they can leave.
At least, a UX that requires installing an app for the service or specifically opening the service's page to see the activities of the people you're following is not interesting, and I don't think you can expect people to install minor apps.

"Please create a mechanism to make content that can only be seen by supporters."

"The content visibility control is positioned low on the priority list on the milestone, but it's a matter of life and death for those who want to sell content, so please make it soon."

"Not just for Bluesky, but please create a mechanism that automatically realizes the experiences I mentioned on various upcoming services."

"It means nothing if only certain services like Bluesky can specially display our content richly.
We don't know if other atproto services will support us in the same way."

"Please make known to ordinary people who are trying to create services the advantages of using atproto from the service provider's perspective."

"From the user's perspective, whether they understand the mechanism or not, the advantages of atproto, such as being able to change service providers at any time and not losing followers even if you move, are somewhat permeating.
Those not keeping an eye on the social media scene, ordinary people who are trying to create content platforms focusing on the user and their business, not technology, should be made aware of the advantages .
You have advantages like reducing infrastructure costs, or users already having an account for your service before you create it, but these are nowhere written on the site."

"I have no complaints about what has been achieved with atproto so far, just that various things are lacking."

The content creator ultimately considers the enshittification by the platform owners, and it's no mistake that the protocol has become one to solve this.
However, the fundamental issues of dissemination power and population have been overlooked.

"Technology to prevent bad actions is meaningless if not used by bad people."

"Who is the target user of this protocol? Since the feature of this protocol is anti-enshittification, it's meaningless if it's not used by people planning enshittification.
Does it make sense to tell someone swinging a knife that here are handcuffs, if you put your hands through them you will no longer be able to swing the knife freely?
It does not bring peace to the world if good people handcuff themselves and say, see, I'm harmless.
I would like to see something that appears attractive to someone swinging a knife, making them want to put the handcuffs on themselves."

"Please take this with a grain of salt."

"I haven't considered every corner case, nor have I done a technical review, and the requirements might be contradictory.
Please take this with a grain of salt.
I still have hope in your protocol.
"

After writing the feedback, I showed it to the developer.
The developer, who thought the protocol was almost finished, was surprised but could largely understand the feeling of me although there are quite a few points he disagrees.
Because they promised to create some mechanism to resolve these issues, I felt it was good that I had built this service and written the feedback.

Context

Hello, I'm K-NKSM, developer of the first third-party atproto service, WhiteWind.
I made a post like the following on Bluesky.

The issue I'm facing is that the contents written in WhiteWind is not automatically shown in Bluesky although WhiteWind is technically a member of the network. The third-party developers will naturally expect their records receive a lot of exposure thanks to federation. (1/4)

— K-NKSM (@knksm5.final-techblog.com) May 7, 2024 at 21:46

Then, Bryan Newbold, an engineer at Bluesky and directly involved in atproto development, asked me the following questions.

do you think full whtwnd posts should render in the bsky app, eg, in feeds? I would assume just a summary or description, which already sort of works via web embed cards.
if it is full posts, then whtwnd posts will be limited by what such apps can render. eg, LaTeX math, tables, interactive JS
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?
I do think it might be helpful if there was some concept of Lexicon schema "traits" or "interfaces".
eg, there could be a meta-schema for records that can be rendered in bsky feeds, with a title, description, and optional image thumbnail; maybe URL. any matching record would display as a card
similar for the opposite: how to reference/render arbitrary atproto records in a whtwnd post?
similar to oEmbed

3456

And so, I wrote this reading material, imagining what would an atproto enthusiast developer think about current atproto!
It would be funny if someone was using social media while seriously thinking about these things 😂!

References

Footnotes

  1. Long text posting sites may have slightly lower expectations of dissemination. Microblog services have dissemination power, and blog platforms have monetization systems, as they have role divisions

  2. 2024 Protocol Roadmap | Bluesky

  3. https://bsky.app/profile/bnewbold.net/post/3krw2j263ep2l

  4. https://bsky.app/profile/bnewbold.net/post/3krw2m7prru26

  5. https://bsky.app/profile/bnewbold.net/post/3krw2tbynmc2g

  6. https://bsky.app/profile/bnewbold.net/post/3krw2vckuqt27

knksm5.final-techblog.com
K-NKSM

@knksm5.final-techblog.com

Making a Markdown blog service using atproto which you can use with Bluesky account!
AT Protocolを使い、Blueskyアカウントがあれば使えるMarkdownブログサービス(AppView)を作っています!
WhiteWind https://whtwnd.com/

X / Twitter: @KNKSM5
Blog: https://blog.final-techblog.com/

Post reaction in Bluesky

*To be shown as a reaction, include article link in the post or add link card

Reactions from everyone (0)