{
"type": "entry",
"published": "2020-10-12T20:36:01Z",
"name": "Micropublish v2.3.0",
"content": {
"text": "I\u2019ve pushed a biggish update to Micropublish to bring it to v2.3.0. It includes some of the stable and experimental Micropub..."
},
"post-type": "article",
"_id": "19381775",
"_source": "189",
"_is_read": true
}
This weekend’s IndieWebCamp in London has sensibly been switched to online-only because of the current health concerns. A big well done to the organisers, Cheuk, Calum and Ana, for their initial...
{
"type": "entry",
"published": "2020-03-13T17:11:06Z",
"content": {
"text": "This weekend\u2019s IndieWebCamp in London has sensibly been switched to online-only because of the current health concerns. A big well done to the organisers, Cheuk, Calum and Ana, for their initial..."
},
"post-type": "note",
"_id": "19381779",
"_source": "189",
"_is_read": true
}
As part of my attempt to work on something IndieWeb every weekend, I decided to do a bit of a dive into the code for https://github.com/kylewm/silo.pub. It’s known as being a (working) example of using Micropub as a means of syndication. Conventionally, people do this using Webmentions via brid.gy - but I am curious about having such a system automatically add syndication back-links to my posts as well as being able to dynamically use it back-fill posts to my site (since it can do the former with potentially less magic than Webmention parsing).
I notice that in order to use silo.pub, you forward the entire incoming Micropub request to the remote endpoint (we can call it ‘syndication endpoint’). This feels a bit tricky to implement because I can see it being simpler as the originating site of the request to only just send a URL of the post that needed to be syndicated - part of the appeal of Bridgy is that. But having to forward the whole thing feels interesting. But it also allows for a means of insuring that a particular syndication location only gets what it can support or what’s appropriate for that destination (bookmarks could be formatted more differently on Twitter or how reading progress is reflected).
I think I can “get” with this approach but I’m going to take a bit of a different approach. Instead of forwarding the whole body, I’m going to send it a request to update a post. Something like the following:
POST /syndication/twitter
{
"action": "update",
"url": "https://jacky.wtf/a-post-to-share"
}
With no other arguments, this would tell the Micropub-powered syndication endpoint that it should update the provided post. Being that this one is optimized for Twitter, it could do the work of sending the tweet (or replying, or liking) and then sending a Micropub update to the original post with the change in the syndication URL. A server noticing that could use that as a way to determine that the syndication was successful with no extra need to add asynchronous processing - we get it for free.
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/75de9b46-72e3-49e9-9606-c6cbff45d7a3",
"content": {
"text": "As part of my attempt to work on something IndieWeb every weekend, I decided to do a bit of a dive into the code for https://github.com/kylewm/silo.pub. It\u2019s known as being a (working) example of using Micropub as a means of syndication. Conventionally, people do this using Webmentions via brid.gy - but I am curious about having such a system automatically add syndication back-links to my posts as well as being able to dynamically use it back-fill posts to my site (since it can do the former with potentially less magic than Webmention parsing).I notice that in order to use silo.pub, you forward the entire incoming Micropub request to the remote endpoint (we can call it \u2018syndication endpoint\u2019). This feels a bit tricky to implement because I can see it being simpler as the originating site of the request to only just send a URL of the post that needed to be syndicated - part of the appeal of Bridgy is that. But having to forward the whole thing feels interesting. But it also allows for a means of insuring that a particular syndication location only gets what it can support or what\u2019s appropriate for that destination (bookmarks could be formatted more differently on Twitter or how reading progress is reflected).I think I can \u201cget\u201d with this approach but I\u2019m going to take a bit of a different approach. Instead of forwarding the whole body, I\u2019m going to send it a request to update a post. Something like the following:POST /syndication/twitter\n\n\n{\n \"action\": \"update\",\n \"url\": \"https://jacky.wtf/a-post-to-share\"\n}\nWith no other arguments, this would tell the Micropub-powered syndication endpoint that it should update the provided post. Being that this one is optimized for Twitter, it could do the work of sending the tweet (or replying, or liking) and then sending a Micropub update to the original post with the change in the syndication URL. A server noticing that could use that as a way to determine that the syndication was successful with no extra need to add asynchronous processing - we get it for free.",
"html": "<p>As part of my attempt to work on something IndieWeb every weekend, I decided to do a bit of a dive into the code for <a href=\"https://github.com/kylewm/silo.pub\">https://github.com/kylewm/silo.pub</a>. It\u2019s known as being a (working) example of using Micropub as a means of syndication. Conventionally, people do this using Webmentions via brid.gy - but I am curious about having such a system automatically add syndication back-links to my posts as well as being able to dynamically use it back-fill posts to my site (since it can do the former with potentially less magic than Webmention parsing).</p><p>I notice that in order to use <code>silo.pub</code>, you <em>forward</em> the entire incoming Micropub request to the remote endpoint (we can call it \u2018syndication endpoint\u2019). This feels a bit tricky to implement because I can see it being simpler as the originating site of the request to only just send a URL of the post that needed to be syndicated - part of the appeal of Bridgy <em>is</em> that. But having to <em>forward</em> the whole thing feels interesting. But it also allows for a means of insuring that a particular syndication location <em>only</em> gets what it can support <em>or</em> what\u2019s appropriate for that destination (bookmarks could be formatted more differently on Twitter or how reading progress is reflected).</p><p>I think I can \u201cget\u201d with this approach but I\u2019m going to take a bit of a different approach. Instead of forwarding the <em>whole</em> body, I\u2019m going to send it a request to update a post. Something like the following:</p><pre><code>POST /syndication/twitter\n\n\n{\n \"action\": \"update\",\n \"url\": \"https://jacky.wtf/a-post-to-share\"\n}</code></pre>\n<p>With no other arguments, this would tell the Micropub-powered syndication endpoint that it should update the provided post. Being that this one is optimized for Twitter, it could do the work of sending the tweet (or replying, or liking) and then sending a Micropub update to the original post with the change in the syndication URL. A server noticing that could use that as a way to determine that the syndication was successful with no extra need to add asynchronous processing - we get it for free.</p>"
},
"post-type": "note",
"_id": "19379104",
"_source": "1886",
"_is_read": true
}
Okay, finally ready to make https://jacky.wtf a static site powered by this new Micropub server. You can peek at the code at https://git.jacky.wtf/indieweb/koype-next but I’ll be aiming to use it to redo a lot of sites (like even https://koype.net because if I can’t use it there then I’m kidding myself, lol)
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/1e446c79-60ea-48b7-93f6-5a29ec1767e8",
"content": {
"text": "Okay, finally ready to make https://jacky.wtf a static site powered by this new Micropub server. You can peek at the code at https://git.jacky.wtf/indieweb/koype-next but I\u2019ll be aiming to use it to redo a lot of sites (like even https://koype.net because if I can\u2019t use it there then I\u2019m kidding myself, lol)",
"html": "<p>Okay, finally ready to make <a href=\"https://jacky.wtf\">https://jacky.wtf</a> a static site powered by this new Micropub server. You can peek at the code at <a href=\"https://git.jacky.wtf/indieweb/koype-next\">https://git.jacky.wtf/indieweb/koype-next</a> but I\u2019ll be aiming to use it to redo a <em>lot</em> of sites (like even <a href=\"https://koype.net\">https://koype.net</a> because if I can\u2019t use it there then I\u2019m kidding myself, lol)</p>"
},
"post-type": "note",
"_id": "19331735",
"_source": "1886",
"_is_read": true
}
It was a treat to chat with @jayeless who has so many interesting interests! Have a listen to the latest episode of the Micro @monday podcast, as we cover: Melbourne, indieweb, linguistics and regional English, Harry Potter houses, and of course, Gidget the cat.
{
"type": "entry",
"author": {
"name": "Jean MacDonald ",
"url": "http://micro.welltempered.net",
"photo": "https://avatars.micro.blog/avatars/2022/61.jpg"
},
"url": "https://micro.welltempered.net/2021/03/22/it-was-a.html",
"content": {
"html": "<p>It was a treat to chat with <a href=\"https://micro.blog/jayeless\">@jayeless</a> who has so many interesting interests! Have a listen to the <a href=\"https://monday.micro.blog/2021/03/22/jess-aka-jayeless.html\">latest episode</a> of the Micro <a href=\"https://micro.blog/monday\">@monday</a> podcast, as we cover: Melbourne, indieweb, linguistics and regional English, Harry Potter houses, and of course, Gidget the cat.</p>",
"text": "It was a treat to chat with @jayeless who has so many interesting interests! Have a listen to the latest episode of the Micro @monday podcast, as we cover: Melbourne, indieweb, linguistics and regional English, Harry Potter houses, and of course, Gidget the cat."
},
"published": "2021-03-22T20:21:12+00:00",
"post-type": "note",
"_id": "33380026",
"_source": "7224",
"_is_read": true
}
Looking forward to talking about all things #IndieWeb, owning your data, and some of the cool open standards and tech we've worked on to take back a bit of control 🤓
Join us next month as we welcome @JamieTanna to talk about the #indieWeb and owning your data!
📅 Free and online Monday 12th April 6.30pm
➡️ nott.tech/tn-apr-2021
{
"type": "entry",
"published": "2021-03-22T11:40:00+0000",
"url": "https://www.jvt.me/mf2/2021/03/zmufv/",
"category": [
"public-speaking",
"indieweb"
],
"quotation-of": "https://twitter.com/technottingham/status/1373917443941359618",
"content": {
"text": "Looking forward to talking about all things #IndieWeb, owning your data, and some of the cool open standards and tech we've worked on to take back a bit of control \ud83e\udd13",
"html": "<p>Looking forward to talking about all things <a href=\"https://www.jvt.me/tags/indieweb/\">#IndieWeb</a>, owning your data, and some of the cool open standards and tech we've worked on to take back a bit of control \ud83e\udd13</p>"
},
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "note",
"refs": {
"https://twitter.com/technottingham/status/1373917443941359618": {
"type": "entry",
"url": "https://twitter.com/technottingham/status/1373917443941359618",
"photo": [
"https://www.jvt.me/"
],
"content": {
"text": "Join us next month as we welcome @JamieTanna to talk about the #indieWeb and owning your data!\n\ud83d\udcc5 Free and online Monday 12th April 6.30pm\n\u27a1\ufe0f nott.tech/tn-apr-2021",
"html": "Join us next month as we welcome <a href=\"https://twitter.com/JamieTanna\">@JamieTanna</a> to talk about the <a href=\"https://twitter.com/search?q=%23indieWeb\">#indieWeb</a> and owning your data!\n\ud83d\udcc5 Free and online Monday 12th April 6.30pm\n\u27a1\ufe0f <a href=\"http://nott.tech/tn-apr-2021\">nott.tech/tn-apr-2021</a>"
},
"post-type": "photo"
}
},
"_id": "19221581",
"_source": "2169",
"_is_read": true
}
{
"type": "entry",
"in-reply-to": [
"https://lukeb.co.uk/blog/2021/03/15/no-comment-adding-webmentions-to-my-site/"
],
"content": {
"text": "this is a very shiny list of webmentions, but it could be even better by using the h-cite pattern http://microformats.org/wiki/h-cite",
"html": "this is a very shiny list of webmentions, but it could be even better by using the h-cite pattern <a href=\"http://microformats.org/wiki/h-cite\">http://microformats.org/wiki/h-cite</a>"
},
"author": {
"type": "card",
"name": "Kevin Marks",
"url": "http://known.kevinmarks.com/profile/kevinmarks",
"photo": "http://known.kevinmarks.com/file/9255656669173b7867ab839ee6556f9e"
},
"post-type": "reply",
"_id": "19196471",
"_source": "205",
"_is_read": true
}
Thinking about this again, it does feel like this could be something that the Micropub server does but would be invoked by some external process. Like if it’s a property (like) that needs to change, then the remote service could perhaps trigger this (could happen from getting a Salmention).
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/4ff97a0c-93ee-4568-9480-8157940905ad",
"in-reply-to": [
"https://github.com/indieweb/micropub-extensions/issues/27"
],
"content": {
"text": "Thinking about this again, it does feel like this could be something that the Micropub server does but would be invoked by some external process. Like if it\u2019s a property (like) that needs to change, then the remote service could perhaps trigger this (could happen from getting a Salmention).",
"html": "<p>Thinking about this again, it does feel like this could be something that the Micropub server does but would be invoked by some external process. Like if it\u2019s a property (<code>like</code>) that needs to change, then the remote service could perhaps trigger this (could happen from getting a <a href=\"https://indieweb.org/Salmention\">Salmention</a>).</p>"
},
"post-type": "reply",
"refs": {
"https://github.com/indieweb/micropub-extensions/issues/27": {
"type": "entry",
"url": "https://github.com/indieweb/micropub-extensions/issues/27",
"name": "Replied to a reply by a remote entity",
"post-type": "article"
}
},
"_id": "19192592",
"_source": "1886",
"_is_read": true
}
@weh_kaniini There are definitely some using Craft for IndieWeb. There's a plugin for v2, but I don't think it's been updated for v3 yet. Details/examples: https://indieweb.org/Craft
{
"type": "entry",
"published": "2021-03-20T05:29:28+00:00",
"url": "http://stream.boffosocko.com/2021/weh_kaniini-there-are-definitely-some-using-craft-for-indieweb-theres",
"syndication": [
"https://twitter.com/ChrisAldrich/status/1373144901785939972"
],
"in-reply-to": [
"https://twitter.com/weh_kaniini/status/1373114510572158979"
],
"content": {
"text": "@weh_kaniini There are definitely some using Craft for IndieWeb. There's a plugin for v2, but I don't think it's been updated for v3 yet. Details/examples: https://indieweb.org/Craft",
"html": "<a href=\"https://twitter.com/weh_kaniini\">@weh_kaniini</a> There are definitely some using Craft for IndieWeb. There's a plugin for v2, but I don't think it's been updated for v3 yet. Details/examples: <a href=\"https://indieweb.org/Craft\">https://indieweb.org/Craft</a>"
},
"author": {
"type": "card",
"name": "Chris Aldrich",
"url": "http://stream.boffosocko.com/profile/chrisaldrich",
"photo": "http://stream.boffosocko.com/file/600427b81f7785e704eadfe511a9270f/thumb.jpg"
},
"post-type": "reply",
"_id": "19174554",
"_source": "192",
"_is_read": true
}
{
"type": "entry",
"published": "2021-03-18T03:55:12+0000",
"url": "http://known.kevinmarks.com/2021/this-is-a-very-shiny-list-of",
"in-reply-to": [
"https://lukeb.co.uk/blog/2021/03/15/no-comment-adding-webmentions-to-my-site/"
],
"content": {
"text": "this is a very shiny list of webmentions, but it could be even better by using the h-cite pattern http://microformats.org/wiki/h-cite",
"html": "this is a very shiny list of webmentions, but it could be even better by using the h-cite pattern <a href=\"http://microformats.org/wiki/h-cite\">http://microformats.org/wiki/h-cite</a>"
},
"author": {
"type": "card",
"name": "Kevin Marks",
"url": "http://known.kevinmarks.com/profile/kevinmarks",
"photo": "http://known.kevinmarks.com/file/9255656669173b7867ab839ee6556f9e"
},
"post-type": "reply",
"_id": "19123760",
"_source": "205",
"_is_read": true
}
Have you read over the IndieAuth spec? I did read the WebID spec some time ago, back when people were toying to expose it in Mastodon and it never went through because it’s not friendly to portability (people change names, identities [think trans, non-binary folks, ex-pats]) nor is it friendly to being used offline
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/a66997c8-13ac-428e-b239-7a4fbd05a33d",
"in-reply-to": [
"https://twitter.com/kidehen/status/1372222356513509377"
],
"content": {
"text": "Have you read over the IndieAuth spec? I did read the WebID spec some time ago, back when people were toying to expose it in Mastodon and it never went through because it\u2019s not friendly to portability (people change names, identities [think trans, non-binary folks, ex-pats]) nor is it friendly to being used offline",
"html": "<p>Have you read over the IndieAuth spec? I did read the WebID spec some time ago, back when people were toying to expose it in Mastodon and it never went through because it\u2019s not friendly to portability (people change names, identities [think trans, non-binary folks, ex-pats]) nor is it friendly to being used offline</p>"
},
"post-type": "reply",
"refs": {
"https://twitter.com/kidehen/status/1372222356513509377": {
"type": "entry",
"url": "https://twitter.com/kidehen/status/1372222356513509377",
"name": "Replied to a article by a remote entity",
"post-type": "article"
}
},
"_id": "19109911",
"_source": "1886",
"_is_read": true
}
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/b286bc3e-b34d-4b8b-964e-40be2b92c53d",
"in-reply-to": [
"https://twitter.com/kidehen/status/1372221277902143501"
],
"content": {
"text": "According to this incubating spec https://www.w3.org/2005/Incubator/webid/spec/ and https://www.w3.org/ns/auth/cert, it does require certificates (I never said TLS) to insure that it\u2019s secure. Otherwise, you\u2019d be reintroducing the era of FireSheep https://en.wikipedia.org/wiki/Firesheep.Also IndieAuth would literally require only one of those \u201crings\u201d.",
"html": "<p>According to this incubating spec <a href=\"https://www.w3.org/2005/Incubator/webid/spec/\">https://www.w3.org/2005/Incubator/webid/spec/</a> and <a href=\"https://www.w3.org/ns/auth/cert\">https://www.w3.org/ns/auth/cert</a>, it <em>does</em> require certificates (I never said TLS) to insure that it\u2019s secure. Otherwise, you\u2019d be reintroducing the era of FireSheep <a href=\"https://en.wikipedia.org/wiki/Firesheep\">https://en.wikipedia.org/wiki/Firesheep</a>.</p><p>Also IndieAuth would literally require only one of those \u201crings\u201d.</p>"
},
"post-type": "reply",
"refs": {
"https://twitter.com/kidehen/status/1372221277902143501": {
"type": "entry",
"url": "https://twitter.com/kidehen/status/1372221277902143501",
"name": "Replied to a article by a remote entity",
"post-type": "article"
}
},
"_id": "19109912",
"_source": "1886",
"_is_read": true
}
If you want something you can give to people tomorrow and keep using as long as the Web is around, use IndieAuth. If you want to yak-shave and use it with three people, WebID’s ideal for that!
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/32cfbd45-384a-4d8f-bad7-a79a4dfdbd2a",
"in-reply-to": [
"https://v2.jacky.wtf/post/bf50f47a-afb5-4824-a60f-8597e96fb330"
],
"content": {
"text": "If you want something you can give to people tomorrow and keep using as long as the Web is around, use IndieAuth. If you want to yak-shave and use it with three people, WebID\u2019s ideal for that!",
"html": "<p>If you want something you can give to people tomorrow and keep using as long as the Web is around, use IndieAuth. If you want to yak-shave and use it with three people, WebID\u2019s ideal for that!</p>"
},
"post-type": "reply",
"refs": {
"https://v2.jacky.wtf/post/bf50f47a-afb5-4824-a60f-8597e96fb330": {
"type": "entry",
"url": "https://v2.jacky.wtf/post/bf50f47a-afb5-4824-a60f-8597e96fb330",
"name": "Replied to a reply by a remote entity",
"post-type": "article"
}
},
"_id": "19108232",
"_source": "1886",
"_is_read": true
}
WebID has to use certificates - you’d be fighting for provider support. It also ignores other clients like phones, CLI tools, etc. IndieAuth’s an extension of OAuth2 - used everywhere. You used it to post this tweet on your phone or sync your e-mail to your phone.
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/bf50f47a-afb5-4824-a60f-8597e96fb330",
"in-reply-to": [
"https://twitter.com/kidehen/status/1372191244454133760"
],
"content": {
"text": "WebID has to use certificates - you\u2019d be fighting for provider support. It also ignores other clients like phones, CLI tools, etc. IndieAuth\u2019s an extension of OAuth2 - used everywhere. You used it to post this tweet on your phone or sync your e-mail to your phone.",
"html": "<p>WebID has to use certificates - you\u2019d be fighting for provider support. It also ignores other clients like phones, CLI tools, etc. IndieAuth\u2019s an extension of OAuth2 - used everywhere. You used it to post this tweet on your phone or sync your e-mail to your phone.</p>"
},
"post-type": "reply",
"refs": {
"https://twitter.com/kidehen/status/1372191244454133760": {
"type": "entry",
"url": "https://twitter.com/kidehen/status/1372191244454133760",
"name": "Replied to a article by a remote entity",
"post-type": "article"
}
},
"_id": "19108233",
"_source": "1886",
"_is_read": true
}
After a bit of a hunting, I think it’ll be very possible to continue building a Micropub server that uses Hypercore/Dat as a storage medium! My long term goal here is to lean on Hypercore to provide a controlled, distributed file system for the flat file storage of posts (instead of leaning on a centralized though self-hostable system like https://min.io/ with free versioning and a means of handling access control for the content. Truthfully, I’d want the Micropub server to have access to two “drives”. We can name them /public for the generated pages of one’s site that then can be automatically available to the general public (or not! the ACL should work on a file-level from the docs so something similar to protected posts could work here) and another /content drive that holds the more intimate details on one’s site - the preprocessed bits like the raw templates, database for just quicker indexing (maybe sticking to SQLite because I’ve invested a lot into SQL, lol) and the raw posts and images.
This is very exciting and potentially the basis of making it easy to automate publishing from your conventional Website into the distributed Web!
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/dd03a6d7-9212-4d60-aef0-a0233166a78c",
"content": {
"text": "After a bit of a hunting, I think it\u2019ll be very possible to continue building a Micropub server that uses Hypercore/Dat as a storage medium! My long term goal here is to lean on Hypercore to provide a controlled, distributed file system for the flat file storage of posts (instead of leaning on a centralized though self-hostable system like https://min.io/ with free versioning and a means of handling access control for the content. Truthfully, I\u2019d want the Micropub server to have access to two \u201cdrives\u201d. We can name them /public for the generated pages of one\u2019s site that then can be automatically available to the general public (or not! the ACL should work on a file-level from the docs so something similar to protected posts could work here) and another /content drive that holds the more intimate details on one\u2019s site - the preprocessed bits like the raw templates, database for just quicker indexing (maybe sticking to SQLite because I\u2019ve invested a lot into SQL, lol) and the raw posts and images.This is very exciting and potentially the basis of making it easy to automate publishing from your conventional Website into the distributed Web!",
"html": "<p>After <a href=\"https://v2.jacky.wtf/post/ab491578-0717-43e9-abf3-4fffa02309ba\">a bit of a hunting</a>, I think it\u2019ll be <em>very</em> possible to continue building a Micropub server that uses Hypercore/Dat as a storage medium! My long term goal here is to lean on Hypercore to provide a controlled, distributed file system for the flat file storage of posts (instead of leaning on a centralized though self-hostable system like <a href=\"https://min.io/\">https://min.io/</a> with free versioning and a means of handling <a href=\"https://github.com/substack/hypercore-authenticate-session-extension\">access control</a> for the content. Truthfully, I\u2019d want the Micropub server to have access to two \u201cdrives\u201d. We can name them <code>/public</code> for the generated pages of one\u2019s site that then can be automatically available to the general public (or not! the ACL <em>should</em> work on a file-level from the docs so something similar to protected posts could work here) and another <code>/content</code> drive that holds the more intimate details on one\u2019s site - the preprocessed bits like the raw templates, database for just quicker indexing (maybe sticking to SQLite because I\u2019ve invested a lot into SQL, lol) and the raw posts and images.</p><p>This is <em>very</em> exciting and potentially the basis of making it easy to automate publishing from your conventional Website into the distributed Web!</p>"
},
"post-type": "note",
"_id": "19090823",
"_source": "1886",
"_is_read": true
}
I want this as well so badly. I can see parts of this already being here in a way with something like https://commentpara.de/. But I think the other bits you mentioned are things we’d still need to investigate - especially in the IndieWeb. I could see https://www.blockpartyapp.com/ even doing some sort of integration to help with the automatic moderation and prevention.
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/ae9483a7-0110-472b-9c95-7ce753c7bb53",
"in-reply-to": [
"https://werd.io/2021/pitch-a-discussion-community-you-can-add"
],
"content": {
"text": "I want this as well so badly. I can see parts of this already being here in a way with something like https://commentpara.de/. But I think the other bits you mentioned are things we\u2019d still need to investigate - especially in the IndieWeb. I could see https://www.blockpartyapp.com/ even doing some sort of integration to help with the automatic moderation and prevention.",
"html": "<p>I want this as well so badly. I can see parts of this already being here in a way with something like <a href=\"https://commentpara.de/\">https://commentpara.de/</a>. But I think the other bits you mentioned are things we\u2019d still need to investigate - especially in the IndieWeb. I could see <a href=\"https://www.blockpartyapp.com/\">https://www.blockpartyapp.com/</a> even doing some sort of integration to help with the automatic moderation and prevention.</p>"
},
"post-type": "reply",
"refs": {
"https://werd.io/2021/pitch-a-discussion-community-you-can-add": {
"type": "entry",
"url": "https://werd.io/2021/pitch-a-discussion-community-you-can-add",
"name": "Replied to a note by a remote entity",
"post-type": "article"
}
},
"_id": "19090526",
"_source": "1886",
"_is_read": true
}
Pitch: a discussion community you can add to any website with one line of code, or embed in any app. Advanced analytics, customization, SSO. Compatible with micropub. Full export. Abuse prevention and moderation. Optionally charge for entry to all or part.
{
"type": "entry",
"published": "2021-03-16T07:45:20+00:00",
"url": "https://werd.io/2021/pitch-a-discussion-community-you-can-add",
"content": {
"text": "Pitch: a discussion community you can add to any website with one line of code, or embed in any app. Advanced analytics, customization, SSO. Compatible with micropub. Full export. Abuse prevention and moderation. Optionally charge for entry to all or part."
},
"author": {
"type": "card",
"name": "Ben Werdm\u00fcller",
"url": "https://werd.io/profile/benwerd",
"photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
},
"post-type": "note",
"_id": "19075969",
"_source": "191",
"_is_read": true
}
{
"type": "entry",
"url": "https://v2.jacky.wtf/post/df01b773-02c7-48e1-8c60-1466d0577a89",
"in-reply-to": [
"https://github.com/hypercore-protocol/hyperdrive/issues/230"
],
"content": {
"text": "Bumping this because I have an interest in using Hyperdrivers as a storage layer for my project\u2019s Micropub server - all IndieWeb technologies.I have seen https://github.com/kappa-db/multifeed but I\u2019d like to see something a bit more supported - especially since https://github.com/kappa-db/multifeed/issues/19 doesn\u2019t seem to be a feature; something that would be critical to this.",
"html": "<p>Bumping this because I have an interest in using Hyperdrivers as a storage layer for <a href=\"https://koype.net\">my project</a>\u2019s <a href=\"https://micropub.spec.indieweb.org/\">Micropub</a> server - all <a href=\"https://indieweb.org\">IndieWeb</a> technologies.</p><p>I have seen <a href=\"https://github.com/kappa-db/multifeed\">https://github.com/kappa-db/multifeed</a> but I\u2019d like to see something a bit more supported - especially since <a href=\"https://github.com/kappa-db/multifeed/issues/19\">https://github.com/kappa-db/multifeed/issues/19</a> doesn\u2019t seem to be a feature; something that would be critical to this.</p>"
},
"post-type": "reply",
"refs": {
"https://github.com/hypercore-protocol/hyperdrive/issues/230": {
"type": "entry",
"url": "https://github.com/hypercore-protocol/hyperdrive/issues/230",
"name": "Replied to a reply by a remote entity",
"post-type": "article"
}
},
"_id": "19071812",
"_source": "1886",
"_is_read": true
}
