friendica / friendica

Friendica Communications Platform
https://friendi.ca
GNU Affero General Public License v3.0
1.41k stars 332 forks source link

Add more information about a server #6743

Open hoergen opened 5 years ago

hoergen commented 5 years ago

It would be nice to see (if available) in which country a public Friendica server is located. And that you can filter via country.

A lot people start looking where a server is located because of privacy concerns.

Every info should be optional.

Maybe we start to add, if a server is hosted in a cloud like AWS or similar. Don't know how to realize that, but maybe we add fields to the admin panel, where admin can add such information.

Some more information could be possible like

This would give the user some more information what he could "expect" AND it would give some more information about the performance of friendica in different environments.

For example this could give someone who wants to install a new Friendica server a little hint maybe not to choose a specific provider, or to choose hardware or VM or docker or or or.

To use all that information we add that to a filter and for example a detailed statistic page in our directory. or as filter?

What do you think?

Again, this all should be optional and additional there should be an extra switch, to publish that information to the directory server. Because some Admins maybe just want to document that on their own server, without publishing it.

What do you think about it?

realkinetix commented 5 years ago

Some of this is great - I think optional info for things like country would be good, and perhaps a few of the other items at the top of your list (cloud, hardware type, provider).

However, some of the rest of the info. suggested wouldn't be great to have Friendica pull itself as it presumes a single host node. From what I hear that's probably 100% of the nodes that are running currently, but as my node grows, I would like to spread it out over a few VMs - DB, worker, front-end, perhaps. Then, what do you do about metrics like load, RAM, cores, etc?

They'd of course all be fine with an on/off selector for that feature, but I kind of doubt a lot of that extra information is going to be useful to 95+% of the population.

bkil commented 3 years ago

I don't think there's much utility in most of the proposed attributes for end users for the following reasons:

1)

Your primary criteria for choosing an instance should be trust based on acquaintance, community and proximity.

1/a)

Both https://podupti.me and https://the-federation.info can already filter by country.

2)

From a user perspective, the only performance related qualities of a service that matters besides SLA is the expected latency of page load (and AJAX interactions) and federation delays (message latency back and forth). Metrics about these could be gathered, aggregated and visualized in a straightforward manner.

2/a)

The mentioned technical parameters also interact in various subtle, but chaotic ways that makes prediction based on them impossible. The underlying technical details shouldn't matter much and they can't really be interpreted independently anyway.

3)

However, from a geeky perspective and as a social experiment, I would also be curious to see such statistics being gathered in a structured way. Many instance operators already share similar information in an unstructured way on their about page.

3/a)

For this, I'm missing lots of extra details that could make a big difference. Let me share just a few.

Site security:

Sustainability:

Operational:

Isolation technology:

Provisioning:

Web stack:

CPU resource allocation:

CPU performance:

Memory allocation:

Storage:

Network:

Power:

hoergen commented 3 years ago

It is okay if you have an opposite meaning,because it is all about taste and the freedom to share information or not. I think it is a bad decision to rely such features on other projects or on other places somewhere on the internet.

Just look at it, as someone who don't have such a deep inside knowledge.

PS: would be nice to not use unnecessary capital numbering. Thank you. #netiquette

bkil commented 3 years ago

These were supposed to be section headers, I did not capitalize them. Could you please clarify which point you would like improved?

I've mentioned in 3/a that I basically agree with you.

If you referred to 1/a, I think the said projects do a GeoIP lookup on the server's IP - no external knowledge needs to be maintained.

hoergen commented 3 years ago

Those information should be voluntarily. Such "automation" like GeoIP is not a good idea since we all try to avoid storing data, that doesn't need to be stored and collected by bots.

bkil commented 3 years ago

Well, that wasn't a proposal or idea on my part - these sites had been operating like that for years, if not decades.

If you operate a public facing server, you must be prepared that anyone will be capable of locating it (based on IP address, TTL, latency or tracepath measurement based triangulation or some other way) to sometimes down to street precision, or in case of better known or frequented server providers, down to a building level.

I don't think that compiling this information into a database and publishing it should be considered breaking the law. It sounds much less sketchy than collecting the colors of mailboxes on your street or wardriving:

Do note that such sites can potentially also collect:

So the bottom line is that privacy and going public are mutually exclusive.

hoergen commented 3 years ago

Please stop nerdsplaining and derailing the topic.. Thank you.