Installation manual.

[ghost]

Hello guys,

first, excellent work. I am trying to start a node here in Europe, but I can't find any manual about how to configure the node, like how to enter/exit the admin mode, and so on.

Could you please suggest a link?

thanks

[1l0]

By running command, it automatically generates directories under $PWD.
Then configurable files are in a 'file' directory:

$ ls
cache   file    log run
$ ls file
initnode.txt    motd.txt    node_allow.txt  node_deny.txt   saku.ini    spam.txt
$ cat file/saku.ini 
#
# Sample saku.ini to run saku in distributed directory.
# Copyright (c) 2005-2011 shinGETsu Project.
# $Id$
#
[Network]
port: 8010

[Gateway]
visitor: ^(127|\[::1\]|192)
enable_nat:false

saku.ini is a main config file. Example is here.

[ghost]

Thank you very much.
This is very useful for a project I am starting.

Actually I have read the code, and I was looking for something like Gou as a code base.

What I want to do is something like GNU Social, of course free and opensource, but I needed the backbone for federating the nodes. Gou is perfect, much better than "Ostatus".

Of course I am mentioning Gou as a codebase on the github, and I am giving all the credits.

[1l0]

That's interesting move.
Is that non backward compatible with shinGETsu on the plan?

BTW, you need to include the original MIT license as well as your GPL, and you need to make it clear that each individual file as a whole is covered by the GPL, as well as MIT for portions of it.
Edit: My bad, he included license in each file. Your structure is fine.

[ghost]

Ok, ok. You can't read my mind, you're right. Let me explain the background and the plan.
At the beginning I did "Tribes": https://github.com/uriel-fanelli/tribes
This is NNTP at localhost, and P2P (DHT) at internet layer. Messages are going Encrypted using AES, and only nodes with the same "TribeID" can join together. TribeID is actually the encryption key. This is to limit spam.

But: people in 2015 doesn't likes to use a News client. Fail. Plus, I developed my TTL-based algorithm for federating on DHT, which I cannot test on big numbers of nodes.
So I was thinking how to produce something better, usable with Web Interface.

My model is to have it to look like the GNU Social node I have now: https://boseburo.ddns.net (to give you an idea).

Then I find this piece of software: Gou :) . And I've to say, the peering mechanism is way simple and robust.
Then I said: ok, this is the P2P backbone I was looking for.
Said that:

Is that non backward compatible with shinGETsu on the plan?

Let's say, what is the "ideal" 1.0 for me:

- Adding identities. (which may be a pure Nickname, so still "anonymous").

As far I see the mechanism you are using, which is a GET on the /cache/thread/something folders, is very robust. I think if I put something instead of "anonymous" (maybe with a link to the original host and BBS) it should resist and keep compatible. Of course I don't know how happy is all the people in Japan to have some non-anonymous people in their network. So, even If it will be compatible, somehow, I've no idea if this is welcome or not.

- Adding a profile page.

To be more "social-like", I will add a personal profile page , which will show in the BBS home page. This is something related to the fact I see this software more like a Diaspora "pod", it means a decentralized, selfhosted entity.

Again, this is not injected in any case into the flow, so It is some piece of "local-only" code. I think this will keep the software compatible. Again, I don't know if the existing network likes to be a "social" network with "groups" instead of BBSs, so I don't know how welcome this is.

• Interface change.

To make more "social like" I will change the templates, in order to look like gnusocial, you can take as example my pod https://boseburo.ddns.net. This is only impacting the templates, then I think yes, in this phase this is still compatible. Again, this will produce social-like phenomena, so I don't know how welcome this is in the existing network. I don't like to disturb other people.

• So basically , I think until the versio 1.0, it is compatible. What about Version 2.0?

I see Gou is missing any kind of antispam/blacklist. The word-based blacklist you have is nice, but is a bit insufficient. Don't take me wrong, you did a great job, but I prefer something "tribe-like".

This means, in the future threads will be encrypted using a "TribeID". This is a long string (like 80Bytes) used as AES encryption key. Nodes which are setup to use the same "TribeID" will be able to federate, the other don't. So you will need to chat with somebody , be trusted, get the tribeID, and then enter the network.

This is for spam protection. And yes, I am sorry to say, this is going to break a bit the protocol.

Also I plan to put a special, hidden BBS, which is the personal inbox of the user, and some "bookmark" functionality, where you bookmark some "friend" you "subscribe". I think I will add it to the cache/thread mechanism, like having a "cache/friends" folder , but then I don't know how this will be welcome in the rest of the network.

Of course, if you agree on this kind of roadmap I would be happy to help and join, but I see that Gou must work together to another system written in python, so I am not sure if you can add such a features.

BTW, you need to include the original MIT license as well as your GPL, and you need to make it       clear that each individual file as a whole is covered by the GPL, as well as MIT for portions of it.

I'm not a big expert on this topic, but I will try to do it.Many thanks for the suggestion.

[1l0]

Thanks for explanation. Your plan looks great.

Don’t worry, owner of each node have responsibility to welcome or not.
I think protocol compatible = valid. Thoughts? @fuktommy

Yes, spam protection is one of hot topics in the last few years on the community. And you have an idea, that will inspire devs definitely.
ShinGETsu is old. It can be said as mature but lacks a lot with a small community / number of developers. So any contributions directly or indirectly are welcomed to grow it up.

About license, my bad, see above.

[ghost]

Hello all,

Utamaro:

1. I will change it to MIT, not probs.
2. Actually I think to do the minimal set of changes only. I'm not that familiar with the code, so it is the best way to begin, I think. This means that I will work where you DON'T put information. What I plan to do is to change the string "anonymous" in the storage, with the email of the sender, so it won't change so much the hashing mechanism (I didn't verified, but I think you don't hash this string). So I can retrieve the icon and profile from gravatar.

Currently I am changing the interface , which is the main difference between a social network and a BBS , so I am focused in the templates. This will also permit me to become familiar with the code, since I see some output comes from the templates, some comes from the code. (Which is making me a bit crazy while formatting pages) . So I think the next push I will do on my repository will be only interface. Then I will ask maybe some feedback.

1|0

I think a reasonable solution is that I go ahead with my repository, mentioning you and giving all the credits, and then you can see what I am doing and how. So you can decide to take the code or not. Unfortunately my Japanese is not as good as I would like, so I can't understand how critical is the "anonymous" thing for your users. By example,here in Germany it is very critical, people is very sensitive to it, so here is not that easy to introduce "identity" in a forum which is used to don't have one. This is why I said I was not sure. But, again, you can check from time to time and decide: I will try to touch the software less than possible.