~rbdr/gemlog

9d336fa9373fb1cac1d6426cfceb1c4f5b573afb — Ruben Beltran del Rio 3 months ago 1344375
blog-sync-up-1705008210785
9 files changed, 40 insertions(+), 79 deletions(-)

A archive/1705007731083/decentralization-depends-on-access.gmi
A archive/1705007731083/metadata.json
A posts/0/decentralization-depends-on-access.gmi
M posts/0/metadata.json
M posts/1/metadata.json
R posts/{0/notes-on-setting-up-a-mastodon-server.gmi => 1/notes-on-setting-up-a-mastodon-server.gmi}
D posts/2/api_notation_updates.gmi
R posts/{1/link-a-claxonomy-of-mexico-citys-traffic.gmi => 2/link-a-claxonomy-of-mexico-citys-traffic.gmi}
M posts/2/metadata.json
A archive/1705007731083/decentralization-depends-on-access.gmi => archive/1705007731083/decentralization-depends-on-access.gmi +15 -0
@@ 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.

A archive/1705007731083/metadata.json => archive/1705007731083/metadata.json +4 -0
@@ 0,0 1,4 @@
{
  "id": "1705007731083",
  "createdOn": 1705007731083
}
\ No newline at end of file

A posts/0/decentralization-depends-on-access.gmi => posts/0/decentralization-depends-on-access.gmi +15 -0
@@ 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.

M posts/0/metadata.json => posts/0/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1704232830490",
  "createdOn": 1704232830490
  "id": "1705007731083",
  "createdOn": 1705007731083
}
\ No newline at end of file

M posts/1/metadata.json => posts/1/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1704107178044",
  "createdOn": 1704107178044
  "id": "1704232830490",
  "createdOn": 1704232830490
}
\ No newline at end of file

R posts/0/notes-on-setting-up-a-mastodon-server.gmi => posts/1/notes-on-setting-up-a-mastodon-server.gmi +0 -0
D posts/2/api_notation_updates.gmi => posts/2/api_notation_updates.gmi +0 -73
@@ 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

R posts/1/link-a-claxonomy-of-mexico-citys-traffic.gmi => posts/2/link-a-claxonomy-of-mexico-citys-traffic.gmi +0 -0
M posts/2/metadata.json => posts/2/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1696437389086",
  "createdOn": 1696437389086
  "id": "1704107178044",
  "createdOn": 1704107178044
}
\ No newline at end of file