✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web.
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.
We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
“The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
- https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
✏️ Suggest Edit
and link it to an edit URL for the static file for the post.
I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.
After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.
It’s an awkward interaction⁵, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb #editableWeb #suggestEdit #acceptEdit
References:
¹ /@kevinmarks%40indieweb.social/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³ https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web.
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks ( @kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.
We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
“The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
✏️ Suggest Edit
and link it to an edit URL for the static file for the post.
I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.
After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.
It’s an awkward interaction⁵, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb#editableWeb#suggestEdit#acceptEdit
References:
¹ /@kevinmarks%40indieweb.social/113025295600067213
²https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks ( @kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.
We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
“The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
✏️ Suggest Edit
and link it to an edit URL for the static file for the post.
I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.
After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.
It’s an awkward interaction⁵, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb#editableWeb#suggestEdit#acceptEdit
References:
¹ /@kevinmarks%40indieweb.social/113025295600067213
²https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
Happy 12 years of https://indieweb.org/POSSE #POSSE and
19 years of https://microformats.org/ #microformats! (as of yesterday, the 20th)
A few highlights from the past year:
POSSE (Publish on your Own Site, Syndicate Elsewhere) has grown steadily as a common practice in the #IndieWeb community, personal sites, CMSs (like Withknown, which itself reached 10 years in May!), and services (like https://micro.blog and Bridgy) for over a decade.
In its 12th year, POSSE broke through to broader technology press and adoption beyond the community. For example:
-
David Pierce’s (@pierce@mas.to) excellent article @TheVerge.com (@verge@mastodon.social): “The poster’s guide to the internet of the future” (https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon):
“Your post appears natively on all of those platforms, typically with some kind of link back to your blog. And your blog becomes the hub for everything, your main home on the internet.
Done right, POSSE is the best of all posting worlds.” -
David also recorded a 29 minute podcast on POSSE with some great interviews: https://podcasts.apple.com/us/podcast/the-posters-guide-to-the-new-internet/id430333725?i=1000632256014
-
Cory Doctorow (@craphound.com @doctorow@mamot.fr) declared in his Pluralistic blog (@pluralistic.net) post: “Vice surrenders” (https://pluralistic.net/2024/02/24/anti-posse/):
“This is the moment for POSSE (Post Own Site, Share Everywhere [sic]), a strategy that sees social media as a strategy for bringing readers to channels that you control” -
And none other than Molly White (@mollywhite.net @molly0xfff@hachyderm.io) of @web3isgoinggreat.com (@web3isgreat@indieweb.social) built, deployed, and started actively using her own POSSE setup as described in her post titled “POSSE” (https://www.mollywhite.net/micro/entry/202403091817) to:
"… write posts in the microblog and automatically crosspost them to Twitter/Mastodon/Bluesky, while keeping the original post on my site."
Congrats Molly and well done!
In its 19th year, the microformats formal #microformats2 syntax and popular vocabularies h-card, h-entry, and h-feed, kept growing across IndieWeb (micro)blogging services and software like CMSs & SSGs both for publishing, and richer peer-to-peer social web interactions via #Webmention.
Beyond the IndieWeb, the rel=me microformat, AKA #relMe, continues to be adopted by services to support #distributed #verification, such as these in the past year:
- Meta Platforms #Threads user profile "Link" field¹
- #Letterboxd user profile website field²
For both POSSE and microformats, there is always more we can do to improve their techniques, technologies, and tools to help people own their content and identities online, while staying connected to friends across the web.
Got suggestions for this coming year? Join us in chat:
- https://chat.indieweb.org/dev
- https://chat.indieweb.org/microformats
for discussions about POSSE and microformats, respectively.
Previously: https://tantek.com/2023/171/t1/anniversaries-microformats-posse
This is post 15 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/151/t1/minimum-interesting-service-worker
→ https://tantek.com/2024/237/t1/people-over-protocols-platforms
Post glossary:
Bridgy
https://brid.gy/ and https://fed.brid.gy/ for direct federation instead of POSSE
CMS
https://indieweb.org/CMS
h-card
https://microformats.org/wiki/h-card
h-entry
https://microformats.org/wiki/h-entry
h-feed
https://microformats.org/wiki/h-feed
microformats2 syntax
https://microformats.org/wiki/microformats2-parsing
rel-me
https://microformats.org/wiki/rel-me
SSG
https://indieweb.org/SSG
Webmention
https://indieweb.org/Webmention
Withknown
https://indieweb.org/Known
References:
¹ https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
² https://indieweb.org/rel-me#Letterboxd
Happy 12 years of https://indieweb.org/POSSE#POSSE and
19 years of https://microformats.org/#microformats! (as of yesterday, the 20th)
A few highlights from the past year:
POSSE (Publish on your Own Site, Syndicate Elsewhere) has grown steadily as a common practice in the #IndieWeb community, personal sites, CMSs (like Withknown, which itself reached 10 years in May!), and services (like https://micro.blog and Bridgy) for over a decade.
In its 12th year, POSSE broke through to broader technology press and adoption beyond the community. For example:
* David Pierce’s ( @pierce@mas.to) excellent article @TheVerge.com ( @verge@mastodon.social): “The poster’s guide to the internet of the future” (https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon):
“Your post appears natively on all of those platforms, typically with some kind of link back to your blog. And your blog becomes the hub for everything, your main home on the internet.
Done right, POSSE is the best of all posting worlds.”
* David also recorded a 29 minute podcast on POSSE with some great interviews: https://podcasts.apple.com/us/podcast/the-posters-guide-to-the-new-internet/id430333725?i=1000632256014
* Cory Doctorow (@craphound.com @doctorow@mamot.fr) declared in his Pluralistic blog (@pluralistic.net) post: “Vice surrenders” (https://pluralistic.net/2024/02/24/anti-posse/):
“This is the moment for POSSE (Post Own Site, Share Everywhere [sic]), a strategy that sees social media as a strategy for bringing readers to channels that you control”
* And none other than Molly White (@mollywhite.net @molly0xfff@hachyderm.io) of @web3isgoinggreat.com ( @web3isgreat@indieweb.social) built, deployed, and started actively using her own POSSE setup as described in her post titled “POSSE” (https://www.mollywhite.net/micro/entry/202403091817) to:
"… write posts in the microblog and automatically crosspost them to Twitter/Mastodon/Bluesky, while keeping the original post on my site."
Congrats Molly and well done!
In its 19th year, the microformats formal #microformats2 syntax and popular vocabularies h-card, h-entry, and h-feed, kept growing across IndieWeb (micro)blogging services and software like CMSs & SSGs both for publishing, and richer peer-to-peer social web interactions via #Webmention.
Beyond the IndieWeb, the rel=me microformat, AKA #relMe, continues to be adopted by services to support #distributed#verification, such as these in the past year:
* Meta Platforms #Threads user profile "Link" field¹
* #Letterboxd user profile website field²
For both POSSE and microformats, there is always more we can do to improve their techniques, technologies, and tools to help people own their content and identities online, while staying connected to friends across the web.
Got suggestions for this coming year? Join us in chat:
* https://chat.indieweb.org/dev
* https://chat.indieweb.org/microformats
for discussions about POSSE and microformats, respectively.
Previously: https://tantek.com/2023/171/t1/anniversaries-microformats-posse
This is post 15 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/151/t1/minimum-interesting-service-worker
→ https://tantek.com/2024/237/t1/people-over-protocols-platforms
Post glossary:
Bridgy
https://brid.gy/ and https://fed.brid.gy/ for direct federation instead of POSSE
CMS
https://indieweb.org/CMS
h-card
https://microformats.org/wiki/h-card
h-entry
https://microformats.org/wiki/h-entry
h-feed
https://microformats.org/wiki/h-feed
microformats2 syntax
https://microformats.org/wiki/microformats2-parsing
rel-me
https://microformats.org/wiki/rel-me
SSG
https://indieweb.org/SSG
Webmention
https://indieweb.org/Webmention
Withknown
https://indieweb.org/Known
References:
¹https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
²https://indieweb.org/rel-me#Letterboxd
19 years of https://microformats.org/#microformats! (as of yesterday, the 20th)
A few highlights from the past year:
POSSE (Publish on your Own Site, Syndicate Elsewhere) has grown steadily as a common practice in the #IndieWeb community, personal sites, CMSs (like Withknown, which itself reached 10 years in May!), and services (like https://micro.blog and Bridgy) for over a decade.
In its 12th year, POSSE broke through to broader technology press and adoption beyond the community. For example:
* David Pierce’s ( @pierce@mas.to) excellent article @TheVerge.com ( @verge@mastodon.social): “The poster’s guide to the internet of the future” (https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon):
“Your post appears natively on all of those platforms, typically with some kind of link back to your blog. And your blog becomes the hub for everything, your main home on the internet.
Done right, POSSE is the best of all posting worlds.”
* David also recorded a 29 minute podcast on POSSE with some great interviews: https://podcasts.apple.com/us/podcast/the-posters-guide-to-the-new-internet/id430333725?i=1000632256014
* Cory Doctorow (@craphound.com @doctorow@mamot.fr) declared in his Pluralistic blog (@pluralistic.net) post: “Vice surrenders” (https://pluralistic.net/2024/02/24/anti-posse/):
“This is the moment for POSSE (Post Own Site, Share Everywhere [sic]), a strategy that sees social media as a strategy for bringing readers to channels that you control”
* And none other than Molly White (@mollywhite.net @molly0xfff@hachyderm.io) of @web3isgoinggreat.com ( @web3isgreat@indieweb.social) built, deployed, and started actively using her own POSSE setup as described in her post titled “POSSE” (https://www.mollywhite.net/micro/entry/202403091817) to:
"… write posts in the microblog and automatically crosspost them to Twitter/Mastodon/Bluesky, while keeping the original post on my site."
Congrats Molly and well done!
In its 19th year, the microformats formal #microformats2 syntax and popular vocabularies h-card, h-entry, and h-feed, kept growing across IndieWeb (micro)blogging services and software like CMSs & SSGs both for publishing, and richer peer-to-peer social web interactions via #Webmention.
Beyond the IndieWeb, the rel=me microformat, AKA #relMe, continues to be adopted by services to support #distributed#verification, such as these in the past year:
* Meta Platforms #Threads user profile "Link" field¹
* #Letterboxd user profile website field²
For both POSSE and microformats, there is always more we can do to improve their techniques, technologies, and tools to help people own their content and identities online, while staying connected to friends across the web.
Got suggestions for this coming year? Join us in chat:
* https://chat.indieweb.org/dev
* https://chat.indieweb.org/microformats
for discussions about POSSE and microformats, respectively.
Previously: https://tantek.com/2023/171/t1/anniversaries-microformats-posse
This is post 15 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/151/t1/minimum-interesting-service-worker
→ https://tantek.com/2024/237/t1/people-over-protocols-platforms
Post glossary:
Bridgy
https://brid.gy/ and https://fed.brid.gy/ for direct federation instead of POSSE
CMS
https://indieweb.org/CMS
h-card
https://microformats.org/wiki/h-card
h-entry
https://microformats.org/wiki/h-entry
h-feed
https://microformats.org/wiki/h-feed
microformats2 syntax
https://microformats.org/wiki/microformats2-parsing
rel-me
https://microformats.org/wiki/rel-me
SSG
https://indieweb.org/SSG
Webmention
https://indieweb.org/Webmention
Withknown
https://indieweb.org/Known
References:
¹https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
²https://indieweb.org/rel-me#Letterboxd