]> git.r.bdr.sh - rbdr/blog.unlimited.pizza/commitdiff
blog-sync-up-1705008210785
authorRuben Beltran del Rio <redacted>
Thu, 11 Jan 2024 21:23:30 +0000 (22:23 +0100)
committerRuben Beltran del Rio <redacted>
Thu, 11 Jan 2024 21:23:30 +0000 (22:23 +0100)
archive/1705007731083/decentralization-depends-on-access.gmi [new file with mode: 0644]
archive/1705007731083/metadata.json [new file with mode: 0644]
posts/0/decentralization-depends-on-access.gmi [new file with mode: 0644]
posts/0/metadata.json
posts/1/metadata.json
posts/1/notes-on-setting-up-a-mastodon-server.gmi [moved from posts/0/notes-on-setting-up-a-mastodon-server.gmi with 100% similarity]
posts/2/api_notation_updates.gmi [deleted file]
posts/2/link-a-claxonomy-of-mexico-citys-traffic.gmi [moved from posts/1/link-a-claxonomy-of-mexico-citys-traffic.gmi with 100% similarity]
posts/2/metadata.json

diff --git a/archive/1705007731083/decentralization-depends-on-access.gmi b/archive/1705007731083/decentralization-depends-on-access.gmi
new file mode 100644 (file)
index 0000000..d6ee1d3
--- /dev/null
@@ -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 (file)
index 0000000..e4fee33
--- /dev/null
@@ -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 (file)
index 0000000..d6ee1d3
--- /dev/null
@@ -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.
index 492517f1a399b7e932ec30753f5b2b9ae365db91..e4fee33be9308e447bd70ac2bd52609dc784ffd0 100644 (file)
@@ -1,4 +1,4 @@
 {
 {
-  "id": "1704232830490",
-  "createdOn": 1704232830490
+  "id": "1705007731083",
+  "createdOn": 1705007731083
 }
\ No newline at end of file
 }
\ No newline at end of file
index 3c9c46f11fccab54927867d3fdfc1fe3a2e8e1bb..492517f1a399b7e932ec30753f5b2b9ae365db91 100644 (file)
@@ -1,4 +1,4 @@
 {
 {
-  "id": "1704107178044",
-  "createdOn": 1704107178044
+  "id": "1704232830490",
+  "createdOn": 1704232830490
 }
\ No newline at end of file
 }
\ No newline at end of file
diff --git a/posts/2/api_notation_updates.gmi b/posts/2/api_notation_updates.gmi
deleted file mode 100644 (file)
index 2585e4a..0000000
+++ /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 <Int>
-  -posts_directory <String>
-  -archive_directory <String>
-  -static_directory <String>
-  -templates_directory <String>
-  -remote_config <String>
-  #add(post_location <String>) => Promise<Void>
-  #update(post_location <String>) => Promise<Void>
-  #publish(host <String>) => Promise<Void>
-  #publish_archive(host <String>) => Promise<Void>
-  #add_remote(remote <String>) => Promise<Void>
-  #remove_remote() => Promise<Void>
-  #sync_down() => Promise<Void>
-  #sync_up() => Promise<Void>
-  #generate() => Promise<Void>
-```
-
-=> 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
-<data type>
-
-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<T>(input T, manipulator<T>(input T, options <ManipulationOptions>) => 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
index 8929a9022740627fccffa24e3f987b6f73769b71..3c9c46f11fccab54927867d3fdfc1fe3a2e8e1bb 100644 (file)
@@ -1,4 +1,4 @@
 {
 {
-  "id": "1696437389086",
-  "createdOn": 1696437389086
+  "id": "1704107178044",
+  "createdOn": 1704107178044
 }
\ No newline at end of file
 }
\ No newline at end of file