Git Product home page Git Product logo

Comments (4)

bill-auger avatar bill-auger commented on June 6, 2024 3

most discussion here so far is revolved entirely around the communication protocol and explicitly that is should be extensions to activity-pub - if you are actually thinking what the server implementation might need to do then kudos to you

im not quite sure what you are suggesting; but i guess you are imagining a server that shuts down and leaves it users with no data? - the foolish user who has put themselves in that position is entirely to blame for that catastrophe - there is no protection for that sort of thing - there does not need to be, and there should not be - in a federated network, each server admin is fully in control of their "home-server" and can turn it off at any time they choose - each user of any network service is 100% responsible for backing up their own data - that should be a commonly known fact by every internet user - if that user no longer wants to publish their code, they do not need to; nor does anyone else need to preserve it - ideally the server admin and the project maintainer are the same person so this is mostly a moot point

the behavior you describe could only be part of the server implementation or some external crawler - it is not something that a protocol spec can or should address - the very nature of federation is that each server is autonomous - any repo can be deleted and any server is free to shut down at any time without warning and it is assumed by all parties that they may do so - there could be a "repo-deleted" message but it would be purely informational - nothing actually needs to happen

does that answer your question? i think this is a non-issue

from forgefed.

jaywink avatar jaywink commented on June 6, 2024 1

Regarding instances disappearing from the network, I once wrote this (messy) draft spec with the aim of protecting identities in a federated network. The idea did evolve into actual work for server to server migration in the Diaspora protocol, but that wasn't the main point of my idea. The main point was to allow automatic (encrypted) identity backup on other servers on the network to allow users to restore their identity on another server, in the case of their home server disappearing.

As bill-auger said, there is no way to force someone to run their server forever. The only way is to somehow make the identities available even if the server disappears. And if this isn't an automated process, I would consider it useless for most users. Only a minority of users will remember to backup (or clone) their external service data. I never do for sure :)

Btw, there is good discussion on this topic in the W3C SocialCG issue tracker.

from forgefed.

shellkr avatar shellkr commented on June 6, 2024

@bill-auger Why I think about this is because it happened Mastodon twice(?). For one it was an instant shutdown and a couple of thousands users was unable to login to their accounts. If one of the biggest instances did this, it would be a devastating blow and could possible even kill the project. It is one of the biggest weaknesses of federation and a sort of paradox. Either you make and host your own instance or you pick the biggest instance in hopes it will live a long time.

You are right that GitPub perhaps is not the right place for this... but why I was thinking of GitPub is because it would probably only be forcible trough the protocol.

Maybe an archive.org kind of bot is the only solution... the issue with such a solution is that it would be really problematic to delete a project. If the protocol handled it.. it could be done reversible throughout the system.

from forgefed.

bill-auger avatar bill-auger commented on June 6, 2024

it is not possible in a federated network to force any node to do anything nor to stop doing something - (do read that sentence again) - all federated nodes are autonomous - that means they and only they decide what to do and when - messages from peers nodes are no more than information upon which the receiver bases it decisions of what to do (or not) - if a server receives a message that says "i (a different server) insist that you delete your repo named 'abc" - the server is just as entitled to ignore as to comply - as well with a message that says "i insist you never power off - you must keep you service running forever" - you could put such messages in the protocol if you like; but every server would probably just ignore them, as they are fully entitled to

it is entirely up to you as the person who is interested in any particular data to backup that data yourself

from forgefed.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.