From: Ruben Beltran del Rio Date: Thu, 11 Jan 2024 21:23:30 +0000 (+0100) Subject: blog-sync-up-1705008210785 X-Git-Url: https://git.r.bdr.sh/rbdr/blog.unlimited.pizza/commitdiff_plain/9d336fa9373fb1cac1d6426cfceb1c4f5b573afb?ds=sidebyside;hp=1344375687c03180e7e99239d5aa08be31c52404 blog-sync-up-1705008210785 --- diff --git a/archive/1705007731083/decentralization-depends-on-access.gmi b/archive/1705007731083/decentralization-depends-on-access.gmi new file mode 100644 index 0000000..d6ee1d3 --- /dev/null +++ b/archive/1705007731083/decentralization-depends-on-access.gmi @@ -0,0 +1,15 @@ +# Decentralization Depends on Access + +After the experience of setting up my own mastodon instance, it's clear that we have a long way to go to make decentralized web services commonplace: As it is right now, it's not really possible to bring up your own instance without a high investment of money and knowledge. This already severly limits the type of people invited to run the "open web". + +The appeal of centralized web services and apps is that it's very easy for anyone to get started because someone else is going to the trouble of setting it up and running it. For decentralization to become the norm we need access to be as easy as that. + +Here's what I think is required: + +1. It should not require a technical person to get started. Running decentralized services should be as easy as installing an app. This is why I like p2p approaches like We, they're very simple as a user even if internally it's complex. +2. It should not require deep pockets to get started. Ideally it should run well on old or low-spec hardware, and it should be available across platforms. +3. It should not require a huge moderation burden upfront. If I can get started with a few of my friends first and I can build a community from there, that's much better. My community and I should be able to control when / if this particular instance joins the general public. +4. It should allow for easy application development. Drag and drop for most cases, with the option to dive into code (i'm thinking of RPG Maker). Replicating services like twitter or youtube is thinking small. If you abstract away the plumbing and let more people build what they want, then we'll start seeing some apps that only decentralization can bring. +5. It should be free / libre. + +I'm sure there's a lot more that goes into it, but I think without those it will never work. People have things to do and problems to solve and will solve them with the tools that they have at hand. I have a lot more faith that peer-to-peer service will achieve this than any of the client-server approaches. diff --git a/archive/1705007731083/metadata.json b/archive/1705007731083/metadata.json new file mode 100644 index 0000000..e4fee33 --- /dev/null +++ b/archive/1705007731083/metadata.json @@ -0,0 +1,4 @@ +{ + "id": "1705007731083", + "createdOn": 1705007731083 +} \ No newline at end of file diff --git a/posts/0/decentralization-depends-on-access.gmi b/posts/0/decentralization-depends-on-access.gmi new file mode 100644 index 0000000..d6ee1d3 --- /dev/null +++ b/posts/0/decentralization-depends-on-access.gmi @@ -0,0 +1,15 @@ +# Decentralization Depends on Access + +After the experience of setting up my own mastodon instance, it's clear that we have a long way to go to make decentralized web services commonplace: As it is right now, it's not really possible to bring up your own instance without a high investment of money and knowledge. This already severly limits the type of people invited to run the "open web". + +The appeal of centralized web services and apps is that it's very easy for anyone to get started because someone else is going to the trouble of setting it up and running it. For decentralization to become the norm we need access to be as easy as that. + +Here's what I think is required: + +1. It should not require a technical person to get started. Running decentralized services should be as easy as installing an app. This is why I like p2p approaches like We, they're very simple as a user even if internally it's complex. +2. It should not require deep pockets to get started. Ideally it should run well on old or low-spec hardware, and it should be available across platforms. +3. It should not require a huge moderation burden upfront. If I can get started with a few of my friends first and I can build a community from there, that's much better. My community and I should be able to control when / if this particular instance joins the general public. +4. It should allow for easy application development. Drag and drop for most cases, with the option to dive into code (i'm thinking of RPG Maker). Replicating services like twitter or youtube is thinking small. If you abstract away the plumbing and let more people build what they want, then we'll start seeing some apps that only decentralization can bring. +5. It should be free / libre. + +I'm sure there's a lot more that goes into it, but I think without those it will never work. People have things to do and problems to solve and will solve them with the tools that they have at hand. I have a lot more faith that peer-to-peer service will achieve this than any of the client-server approaches. diff --git a/posts/0/metadata.json b/posts/0/metadata.json index 492517f..e4fee33 100644 --- a/posts/0/metadata.json +++ b/posts/0/metadata.json @@ -1,4 +1,4 @@ { - "id": "1704232830490", - "createdOn": 1704232830490 + "id": "1705007731083", + "createdOn": 1705007731083 } \ No newline at end of file diff --git a/posts/1/metadata.json b/posts/1/metadata.json index 3c9c46f..492517f 100644 --- a/posts/1/metadata.json +++ b/posts/1/metadata.json @@ -1,4 +1,4 @@ { - "id": "1704107178044", - "createdOn": 1704107178044 + "id": "1704232830490", + "createdOn": 1704232830490 } \ No newline at end of file diff --git a/posts/0/notes-on-setting-up-a-mastodon-server.gmi b/posts/1/notes-on-setting-up-a-mastodon-server.gmi similarity index 100% rename from posts/0/notes-on-setting-up-a-mastodon-server.gmi rename to posts/1/notes-on-setting-up-a-mastodon-server.gmi diff --git a/posts/2/api_notation_updates.gmi b/posts/2/api_notation_updates.gmi deleted file mode 100644 index 2585e4a..0000000 --- a/posts/2/api_notation_updates.gmi +++ /dev/null @@ -1,73 +0,0 @@ -# API Notation Updates - -A few years ago I created an API notation to use with software specification documents: Back then I was working in a team that relied heavily on software specifications, and we were maintaining projects in objective-c, ruby, and javascript, so the notation emerged out of the need to communicate the public APIs in a way that was generic enough to make implementation in any language simple, while concise enough to avoid integration issues. - -For example, I could use it to describe the library I use to build this blog[1] - -``` -// Library to generate an ephemeral html blog with a gemini archive -Blog - -max_posts - -posts_directory - -archive_directory - -static_directory - -templates_directory - -remote_config - #add(post_location ) => Promise - #update(post_location ) => Promise - #publish(host ) => Promise - #publish_archive(host ) => Promise - #add_remote(remote ) => Promise - #remove_remote() => Promise - #sync_down() => Promise - #sync_up() => Promise - #generate() => Promise -``` - -=> https://git.sr.ht/~rbdr/blog/tree/main/item/lib/blog.js [1] A Javascript implementation of that API - -I had been using it unchanged for almost ten years, but recently decided to drop a specific symbol for callbacks, and instead add a "Throws" symbol #>. You can see the definition here, or in its home page[2] - -``` -// Anything after two forward slashes is a comment -NameOfClass.WithPossibleNamespace - + class property - - instance property - ~> listened events (socket) - +> listened events (class/module) - -> listened events (instance) - <~ dispatched events (socket) - <+ dispatched events(class/module) - <- dispatched events (instance) - :: class method - # instance method - -Other symbols - => returns - #> throws -[xx] optional - - -Recommended order: class first, then sockets, then instance. Internally: -Properties, events, methods. -``` - -One of the patterns that I started using for functions is to instead define the whole function signature as part of the type definition. So for example, if you have a method that receives a function as an argument, you could write the following: - -``` -GenericManipulator - #manipulate(input T, manipulator(input T, options ) => T #> ManipulationError) => T #> ManipulationError -``` - -I've found this pattern covers most cases where I need to pass a function. - -In slightly related news, since I've recently moved fully to using `neovim`, I've also created a tree-sitter parser[3] that you can use as a neovim plugin. It was really fun to learn, but the documentations was clear and easy to follow. A bit less easy to follow was how to get the syntax highlighting to actually work with neovim, but it ended up working. - -=> https://www.unlimited.pizza/api.html [2] API definition -=> https://git.sr.ht/~rbdr/tree-sitter-api-notation [3] tree-sitter parser and neovim plugin. - -If you use other editors, there's older versions of the plugin available for vim[4], vscode[5], and TextMate / Sublime Text[6]. They don't support the #> throws notation. - -=> https://git.sr.ht/~rbdr/api-notation.vim [4] Syntax for vim -=> https://git.sr.ht/~rbdr/api-notation.vscode [5] Syntax for vscode -=> https://git.sr.ht/~rbdr/api-notation.tmLanguage [6] Syntax for TextMate and Sublime text diff --git a/posts/1/link-a-claxonomy-of-mexico-citys-traffic.gmi b/posts/2/link-a-claxonomy-of-mexico-citys-traffic.gmi similarity index 100% rename from posts/1/link-a-claxonomy-of-mexico-citys-traffic.gmi rename to posts/2/link-a-claxonomy-of-mexico-citys-traffic.gmi diff --git a/posts/2/metadata.json b/posts/2/metadata.json index 8929a90..3c9c46f 100644 --- a/posts/2/metadata.json +++ b/posts/2/metadata.json @@ -1,4 +1,4 @@ { - "id": "1696437389086", - "createdOn": 1696437389086 + "id": "1704107178044", + "createdOn": 1704107178044 } \ No newline at end of file