-
btw there’s an app that I don’t see on this list: How might I go about finding a community of people that want to work together building a federated version?
-
-
The nice thing about the activity stream spec is that it can capture many different types of interaction. Writing a blogpost, sending an email, listening to a song, sharing something etc. All of these are easy to model so its a very general spec.
I like the tech, it’s just that distributed protocols are struggling at the moment. I doubt it will succeed.
-
-
-
ActivityPub strikes me as the invention of people who believe that the internet = HTTP, and who know about JSON but not RFC822.
Some of the example message bodies just look like JSON-ized SMTP headers, “inReplyTo” etc. It looks like it has a MIME-inspired “mediaType” attribute too, but does it allow only one media type per message?
Can someone who is more familiar with ActivityPub give me the sales pitch about why existing protocols don’t suffice?
-
RFC822 is ASCII only to begin with one of the biggest limitations of email related “standards”.
Some 6.5 billion people around the globe use non-ascii charecters, and old standards only have layers of hacks upon them to support their usecases to some extent.
Why not create new standards from the ground up for the current usecases? I’m not interested in ActivityPub curently, but I have some experience with email and related technologies, and it badly needs a redesign. It won’t happen as none of the parties capable to organise it is interested in it.
-
My uninformed guess is that with the slow decline of email, there are more & better JSON parsers than there are MIME or email parsers. I would have made the same choice, but my reason would have revolved around JSON’s ability to store structured data, for future flexibility.
-
-
I think it comes down to tooling. Protocol A could be 10x as widely deployed as protocol B, but if protocol B has better libraries, I’ll give that more weight in my decision of which to use. I had to assemble a multipart MIME message for work a few weeks ago, and everything about the experience was inferior to “create a data structure and convert it to JSON”.
Coders are likely to pick the easiest path, if everything else is roughly equal.
-
-
-
-
SMTP is forever tainted by spam. ISPs like to block ports, spam filters like to eat mail from new unknown servers, etc.
Giving a pitch for Webmention instead of ActivityPub: Webmention requires the sender to publish an html page that actually links to the target URL. You can be stricter and require a valid microformats2 reply/like/repost/bookmark. That already stops old school pingback spam. For stronger protection, there are clever schemes based on “this non-spam domain you linked to has linked to me”.
-
-
-
Fun :) I added gopher support to Pleroma a while ago (
lynx gopher://pleroma.soykaf.com:9999), it’s a nice little protocol!
-
Interestingly noone seems to bring up these valid arguments when discussing E-Mail. It’s the same distribution model, but either everyone deems it to be a lost cause or does not know/care.
All these federated social media discussions can be dehyped if you explain it like you’d explain e-mail…
-
This article is specifically about privacy. E-mail is well-known to have very poor privacy, to that point that it is often singled out by privacy-related regulatory schemes (like HIPAA) which require additional privacy-protecting measures (like user-level encryption). And email’s privacy weaknesses are the same as those pointed out by the author of this article: you must trust the operators of the federated nodes, and in a federated environment you may not even know all of the nodes you are trusting.
-
-
E2E encryption is only part of the story. You also need to solve the metadata problem, which is where Cwtch comes in.
-
-
-
There are also federated platforms that provide decent privacy. Matrix supports E2E encrypted messaging so the server only knows who you talk to and not the contents of the messages. The only system I have seen that obfuscates the receiver is bitmessage which works by sending your message to everyone and everyone tries to decrypt it to see if it was sent to them.
-
It’s not completely one-to-one (at least, with modern email systems, as opposed to getting local unix mail federated on whatever machine you have a shell on thirty years ago), since there’s no sense of users on the local node being closer than users on a remote node anymore. A better match would be usenet, since the number of hops matters more.
(Of course, if you don’t look at the local timeline, the fediverse doesn’t have much to do with locality except in terms of general visibility of remote hosts, which you as an unprivileged user have near-total control over.)
-
-
As I read this I thought about my experiences with Diaspora and Mastodon. Pages like this one or this one (click “Get Started”, I couldn’t do a deep link because JavaScript) are, IMHO, a big part of the reason these services don’t take off. How can an average user be expected to choose from a basically random list of nodes? How can I, a reasonably “technical” person, even be expected to do so?
So then why not host my own node? First, I don’t have time and most people I know don’t either. If I was 15 again I totally would because I had nothing better to do. I also don’t want to play tech support for a good chunk of my social network, and providing a service to someone has a tendency to make them view you as the tech support.
Second, if I do that I’m now in charge of security for my data. As terrible as Twitter and Facebook are, they’re probably still a lot better at securing my data than I am (at the very least they probably patch their systems more often than I would). Even worse, if some non-technical person decides to bite the bullet and create a node for his/her friends, how secure do you think that’s going to be?
Further, what are the odds that I, or whoever is maintaining the node, basically gets bored of it one day and kills the whole thing? Pretty damn high (maybe I and all my friends are assholes, though, so whatever).
Anyway, this post really spoke to me because I’ve been trying to escape Evil companies for awhile now and “federated” just doesn’t seem to be the answer. I now believe that centralized is here to stay, but that we should start looking at the organizations that control the data instead of the technology. For example, if Facebook were an open non-profit with a charter that legally prevented certain kinds of data “sharing” and “harvesting” maybe I wouldn’t have any problem with it.
-
How can an average user be expected to choose from a basically random list of nodes?
How did they choose their email provider? Not be carefully weighing the technical options, surely. They chose whatever their friends or parents used, because with working federation it doesn’t matter.
what are the odds that I, or whoever is maintaining the node, basically gets bored of it one day and kills the whole thing?
Same as what happened with many early email providers: when they died, people switched to different ones and told their friends their new addresses.
Really, all this argument of “what if federation isn’t a holy grail” is pointless because we all already use a federated system — email — and we know for a fact that it works for humans, despite all its flaws.
-
How did they choose their email provider? Not be carefully weighing the technical options, surely. They chose whatever their friends or parents used, because with working federation it doesn’t matter.
In contrast to mastodon instances - which are very alike - email providers have differentiated on the interface and guarantees they provide and market that. People react to that.
-
In contrast to mastodon instances
While this was largely true in the beginning, many Fediverse nodes now do market themselves based on default interface, additional features (e.g. running the GlitchSoc fork or something like it), or even using non-Mastodon software like Pleroma. I suspect this will only increase as additional implementations (Rustodon) and forks (#ForkTogether) take off and proliferate.
-
-
How did they choose their email provider?
I think federated apps like Mastodon are fundamentally different than email providers. Most email providers are sustainable businesses, they earn money with adds or paid plans or whatever and have their own emails servers and clients with specific features. Self-hosted email servers are a minority. Please tell if I wrong, but I don’t think one can easily earn money with a Mastodon instance.
However I agree that both are federated.
-
-
You’re certainly not wrong, though I would argue that email, particularly as it was 20+ years ago when it went “mainstream”, is much simpler (for instance, it doesn’t require any long-term persistence or complicated access control) and therefore easier to federate successfully (in a way that humans can handle) than social networking.
-
-
-
-
-
Email is basically fire and forget. You download it to your computer and then you’ve got it forever (modern email does more, but also includes more of the privacy / data issues that come with other social networks). But most users can’t easily give other people on-demand access to their emails, which is the case with Facebook, Twitter, etc. Email is really meant for private communication (possibly with a large group, but still private), Facebook and company are for private, semi-private, and even public communication, and they require a user to be able to easily retroactively grant or retract permissions. Email doesn’t handle these other use-cases (this isn’t a fault of email, it doesn’t try to).
-
-
-
The ability for interested parties to interact without reply all. I can post a picture of a beautiful burrito, and people can comment or ignore at their leisure, and then reply to each other. I guess there’s some preposterous email solution where I mail out a link to an ad hoc mailing list with every update and various parties subscribe, but… meh.
-
-
-
-
In the case of Mastodon, which instance you pick does matter. Users can make posts that are only visible to others in the same instance. If you pick the “wrong” home instance, you’ll have to make another account in another instance to see the instance-private posts there. If you’re a new Mastodon user, you might not know that one instance is good for artists and another good for musicians, etc. In any case, this is as easily solvable problem by adding descriptions and user-provided reviews to each instance.
-
-
-
Second, if I do that I’m now in charge of security for my data. As terrible as Twitter and Facebook are, they’re probably still a lot better at securing my data than I am
Setting a price tag on your datas doesn’t secure them. There are enough scams and hoaxes on Facebook to share your information with other companies that I have to disagree with you. And since those social networks are collecing more data than necessary, it is easier to lose data.
-
Facebook and Twitter also present single valuable targets and are thus more likely to be targeted. A hundred mastodon instances may be individually less secure due to the operators having fewer resources or less experience, but compromising a single server won’t get you as much.
-
-
-
-
Amazing how this article can talk about how great the fediverse is (a network that exists for nearly a decade now) without once using the word or mentioning its history.
-
-
Except the whole post is about the fediverse? It’s right there staring you in the face in bold.
The social network that is Mastodon isn’t really Mastodon. It’s bigger.
-
-
What makes you say that? (Well, other than the fact that I guess it’s strictly “good” for the Mastodon brand if Mastodon and only Mastodon becomes identified with ActivityPub federation, in the same way that it’s “good” for the kleenex brand if kleenex becomes identified with all tissue paper)
-
-
GNU/social et al?
-
Yes, it’s all the same network. See https://fediverse.network/.
-
-
-
Saying no really is just part of the development process, I’m surprised that contributors would be angry about that. From my experience, most free software projects are reasonably welcoming. The problems with onboarding new contributors usually are:
- PRs getting no reaction for a long time. People think their code isn’t needed or wanted. I think it’s good to even do a quick comment like “I don’t have time to review this right now” or “I think this part needs reworking”), at least it makes the other person know that they are not being ignored.
- People not being brave enough to actually do a PR. I’ve seen people post so much about things like “I got it to work, but the code is so ugly, I’ll never do a PR”. I’ve had to bug people for weeks to get them to make an PR, and it was pretty much perfect code, but they still were nearly too nervous to do it.
- Replies with rework requests but without any pointers on how to do it. If a beginner doesn’t know the structure of a program, even just telling them in which files they should look for something can be a big help.
-
The problem with riot isn’t typography or that it’s ‘too busy’, the problem is that it’s really slow and heavy, and synapse is as well.
-
-
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
They should have never used Python in the first place. That was their big mistake. I honestly believe their rewrite will be a failure.
-
I’ve been reading their code for quite a while now, and from what I can see, this is all just a new UI, but the problematic parts aren’t getting fixed at all. They admitted that they just don’t have the manpower for that.
Matrix has so much potential, but with this, they won’t get anywhere.
-
-
-
-
-
-
-
The performance improvements seem to be substantial this time.
-
As they have no business model that would allow them to actually care for their users, I’d suggest just not using twitter. There are more than enough alternatives by now (https://fediverse.network/)
-
My observation about Best Practices is that the ones worth listening to are often:
- the result of colossal fuckups or near misses
- quietly known to conservative engineers who encountered them on a team, documented them, and don’t make a fuss
- very different from whatever is being proclaimed in the mailing-lists and blogs
- arose during fighting common problems on real products
All too frequently (looking at you Dave Thomas, Uncle Bob, many security folks and academics, and others) there seems to be a tendency to have practices that:
- are meant to address theoretical concerns that don’t occur during normal development or operations
- are given “Best Practices” status by handwaving about “the community has decided” (Thomas’s first edition of Programming Elixir was rotten with this) when the community is both very young and new
- arose fighting uncommon problems on real products (lots of FB/GOOG/AMZN Best Practices make sense only in their operational regime…blindly following them is not good engineering)
- rely really heavily on a commercial/philosophical context that you probably don’t share
-
-
Best Practices are worthwhile only when understood. Why is this a best practice? If you cannot understand it, then don’t follow it and learn why you should (or shouldn’t) follow it.
Blindly putting them aside is also a mistake since you refuse to learn why some people wrote about them.
-
arose fighting uncommon problems on real products (lots of FB/GOOG/AMZN Best Practices make sense only in their operational regime…blindly following them is not good engineering)
This is probably the worst mind virus, at least the one I encounter most often. This leads to stuff like basic websites using Redis, Elasticsearch, Cloudflare, a RDBMS, docker, kybernetes, etc…
-
There’s also this script which can auto-setup a TOR Pleroma instances: https://gist.github.com/majestrate/d6559d885910a5635943f66093723dba
-
Realtime federated chat over ActivtityPub
-
-
You can even do your social networking in gopher: https://blog.soykaf.com/post/gopher-support-in-pleroma/
-
A matrix server isn’t like “freenode”. Matrix itself is like freenode. There’s no advantage you get by choosing one matrix server over another, you can join all rooms regardless.
-
Nice Video, but once again, conflates the fediverse with Mastodon.
-
Nothing hugely shocking here. If you have a decentralized system without end to end crypto then servers can read all your stuff, its the same with email and gmail scanning all of your emails.
-
Which is why we shouldn’t build decentralised (or centralised) systems without end-to-end crypto any longer.
There’s no reason why something like Mastodon couldn’t have anonymous (unsigned, unencrypted), public (signed, unencrypted), group (signed, encrypted to a group — ‘friends’ is merely one group), and unlisted (signed, encrypted) posts. Yes, there are some key management challenges (particularly around key management & re-encryption as one adds & deletes friends), but they are no insurmountable.
I strongly believe that writing systems without cryptographically-strong privacy in 2018 is an error.
-
-
-
Well off the top of my hat, key management issues arise whenever you try to use it across multiple machines. Now you could manually copy the key from machine to machine, but if you ever use two machines simultaneously it creates a sort of fork in your identity on the network, which causes plenty of trouble.
There are a few solutions under research, most notable a master / slave system, but last time I checked it was still very much in the design phase.
-
-
-
This is easily said, but both end to end crypto and key management add a huge amount of complexity to the system. If you need the privacy that e2e can provide, this is of course worth it, but it’s not at all clear that every service needs this. The fediverse is meant for public and targeted messages, not private ones. For those usecases, people can easily use e2e encrypted systems like matrix or gpg.
-
Hear hear! I think everyone has this vision of a perfect crypt-opia where we can conduct our social networking safe from the prying eyes of government or BigCorps, but the realities of making this happen are as you say not at all trivial.
It’s a great goal, and one I think people should continue working towards, but the logistics are hard.
-
-
I don’t know if I agree. When I publish toots on Mastodon, all they know is that feoh@amicable.feoh.org said blah blah blah.
When I use Facebook, they are collecting a SUPER rich trove of demographic data on me, cross referencing it with other commercial sources (my employer for one :) and linking it in with my “social graph” where my friends data is taken into account. It’s the difference between a linked list of nodes with 2 or 3 fields and a full on acyclic graph with zillions of nodes and zillions more connections.
-
all they know is that feoh@amicable.feoh.org said blah blah blah.
Anyone can also see who you are following, who you reply too, whos posts you like, what kind of content you like and then draw a graph based on this data. The main thing you lose is the tracking using apps to see more than what you post but a huge huge amount of data anyone can see can be used to track you and build a profile on you.
-
By ‘anyone’ you mean ‘any Fediverse user’ right? Also there’s a huge difference between having to scrap the correlate vast gobs of data yourself and having it handed to you for analysis on a silver platter by the platform.
Anyway, this is silly. I agree that social media is at odds with privacy to an extent, but some platforms are factually, provably better than others.
-
-
-
-
-
also there’s nothing stopping you from using clientside tools that provide this.
-
-
-
How would you do this while still allowing mastodon to be used from a web interface? If it’s implemented using javascript you’re in the exact same situation of having to trust the instance administrator.
-
-
Exactly. You said that there’s no reason why it couldn’t do this, there’s your reason.
-
-
-
-
agreed. It seems mostly useful for like novices.
-
-
If you store things on other people’s servers they are on other people’s servers. I don’t see how this statement is a resignation. If you want your posts to be private in the fediverse, encrypt it. If you want your emails, posts,etc to be private, encrypt them.
-
I was not talking about @mercer article: as you said it can be pretty useful for novices.
What scares me is that we could design something better, but there is not much research about the topic.
No one really try to challenge the status quo with original engineering solutions, in a sort of resignation.
At best, people are waiting for mathematicians to create a cheap fully homomorphic encryption scheme.
But I’m afraid it’s not lazyness, but lack of vision, interest and hope.
-
Vision, interest, and hope are not valid inputs to compilers.
I think a reasonable compromise in new system design (taken in some side projects of mine) is to assume that the channels of communication are compromised by hostile actors, that storage exists in the datacenters of hostile actors who are actively trying to munge through the contents, and that mere possession of encrypted material is of significant interest to the hostile actors.
You end up with a sort of “I am Spartacus” setup for communication systems under those constraints, where everybody by definition has open-access to all communications but all communications are also encrypted such that if you have a key you can read it and otherwise you are just providing storage–and because everybody has copies of the content, the metadata of how it moves through the system is not super interesting. Of course, the flipside is that participation in such a system is almost always a red flag.
-
-
If you can’t read the code on the server, and you can’t, then you can’t know it was actually encrypted. The only thing you can do is end to end encryption, which you can already do on top of all of these existing services. What we need is education of the tools that already exist and also improving ease of use. The moment you put the tech on the server you’ve already lost. Otherwise the tech you’re describing already exists.
-
I agree with you about education. I deeply agree.
But with fully homomorphic encryption you can know it’s encrypted even without seeing the code.
I’m not entirely sure that no other mitigation is possible: my insight is that too few have tried to challenge the http/dns/browser/javascript stack to get a chance to find a solution.
My bet is that we just need to open our minds.
Still, you are right: there’s no cloud, just another person’s computer… ;-)
-
-
-
-
-
-
-
There really needs to be a federated github.
-
-
-
-
But did GitHub really centralize something decentralized? Git, as a VCS is still decentralized, nearly everyone who seriously uses it has a git client on their computer, and a local repository for their projects. That part is still massively decentralized.
GitHub as a code sharing platform, that allows issues to be raised and discussed, patches/pull requests to be submitted, etc. didn’t previously exist in a decentralized manner. There seems to have always been some central point of reference, be it website or just a mailing list. It’s not as if whole project were just based around cc’ing email to one another all the time. How would new people have gotten involved if that were the case?
The only thing I could see as centralising is the relative amount of project hosted on GitHub, but that isn’t really a system which can be properly described as “decentralized” or “centralized”..,
-
It’s the degree to which people are dependent on the value-adds that github provides beyond git. It’s like a store having a POS that relies on communication with a central server. Sure, they can keep records on paper do sales but it’s not their normal course, so they don’t. This comment on HN sums it up: https://news.ycombinator.com/item?id=16124575
-
-
-
Email would be a prominent one. Most people (and I can’t say I am innocent) use gmail, hotmail, yahoo mail, etc. I belive there is some general law that describes this trend in systems, which can then be applied to the analysis of different topics, for example matter gathering in around other matter in physics or money accumulating itself around organization with more money, etc.
On the other side you have decentralized systems which didn’t really centralized significantly, for whatever reason, such as IRC, but which had a decrease in users over time, which I also find to be an interesting trend.
-
-
A tendency towards centralisation doesn’t mean that no smaller email servers exist, I’m sorry if you misunderstood me there. But on the other hand, I have heard of quite a few examples where businesses just use gmail with a custom domain, so there’s that.
And it’s true that you don’t have to be on gmail to send an email to a hotmail server, for example, but most of the time, if just a normal person were to set up their mail server, all the major mail providers automatically view this new host as suspicious and potentially harmful, thus more probably redirecting normal messages as spam. This wouldn’t be that common, if the procentual distribution of mail servers weren’t that centralised.
-
-
-
Did a talk using them. This cuts to the chase: https://www.youtube.com/watch?v=MgbmGQVa4wc#t=11m35s
-
-
-
-
-
… federation is about data/communications between servers.. but seeing as you asked, yes it does: https://manpages.debian.org/stretch/git-man/gitweb.1.en.html
-
-
-
But you then miss out on issue tracking, PR tracking, stats, etc. I agree that Git itself provides a decentralized version control system. That’s the whole point. But a federated software development platform is not the same thing. I would personally be very interested to see a federated or otherwise decentralized issue tracking, PR tracking, etc platform.
EDIT: I should point out that any existing system on par with Gitea, Gogs, GitLab, etc could add ActivityPub support and instantly solve this problem.
-
-
git-appraise exists. Still waiting for the equivalent for issues to come along.
-
huh git appraise is pretty cool.
I was going to suggest some kind of activitypub/ostatus system for comments. A bit like peertube does to manage comments. But a comment and issue system that is contained within the history of the project would be really interesting. Though it would make git repos take a lot more space for certain projects no?
-
I’d assume that those could potentially be compressed but yes. It’s definitely not ideal. https://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
^^^^ Unless I’m mistaken, Fossil also tracks that kind of stuff internally. I really like the idea that issues, PRs, and documentation could live in the same place, mostly on account of being able to “go back in time”, and see when you go back to a given version, what issues were open. Sounds useful.
-
-
-
BugsEverywhere (https://gitlab.com/bugseverywhere/bugseverywhere), git-issues (https://github.com/duplys/git-issues), sit (https://github.com/sit-it/sit) all embed issues directly in the git repo.
Don’t blame the tool because you chose a service that relies on vendor lock-in.
-
-
-
Right, and there are literally dozens of git web interfaces.
Literally dozens of git web interfaces the majority of developers either don’t know or care about. The developers do use GitHub for various reasons. voronoipotato and LeoLamda saying a “federated Github” means the alternative needs to look like or work with Github well enough that those using Github, but ignoring other stuff you mentioned, will switch over to it. I’m not sure what that would take or if it’s even legal far as copying appearance goes. It does sound more practical goal than telling those web developers that there’s piles of git web interfaces out there.
-
Im going to respond to two points in reverse order, deliberately:
or care about.
Well, clearly the person I replied to does care about a git web interface that isn’t reliant on GitHub.com. Otherwise, why would they have replied?
Literally dozens of git web interfaces the majority of developers either don’t know [about]
Given the above - The official git project’s wiki has a whole page dedicated to tools that work with git, including web interfaces. That wiki page is result 5 in google and result 3 in duckduckgo when searching for “git web interface”. If a developer wants a git web interface, and can’t find that information for themselves, nothing you, or I or a magic genie does will help them.
-
-
-
-
-
-
-
-
-
-
It won’t happen for a while due to network effects. They made it easy to get benefits of a DVCS without directly dealing with one. Being a web app, it can be used on any device. Being free, that naturally pulls people in. There’s also lots of write-ups on using it or solving problems that are a Google away due to its popularity. Any of these can be copied and improved on. The remaining problem is huge amount of code already there.
The next solution won’t be able to copy that since it’s a rare event in general. Like SourceForge and Github did, it will have to create a compelling reason for massive amounts of people to move their code into it while intentionally sacrificing the benefits of their code being on Github specifically. I can’t begin to guess what that would take. I think those wanting no dependency on Github or alternatives will be targeting a niche market. It can still be a good one, though.
-
I hear the ‘network effects’ story every time, but we are not mindless automatons who have to use github because other people are doing it. I’m hosting the code for my open source projects on a self-hosted gitlab server and i’m getting contributions from other people without problems. Maybe it would be more if the code was on github, but being popular isn’t the most important thing for everyone.
-
Just look at sourceforge, if everyone had to set up their own CVS/SVN server back in the say do you think all those projects would have made it onto the internet?
Now we have a similar situation with got, if GitHub/Bitbucket/etc. didn’t exist I’m sure most people would have stuck with sourceforge (Or not bothered if they had to self host).
You can also look at Googlecode to see the problem with not reaching critical mass (IMHO). There were some high profile projects there, but then I’m sure execs said, why are we bothering to host 1% (A guess) of what is on GitHub?
-
‘Network effects’ doesn’t mean you’re mindless automatons. It means people are likely to jump on bandwagons. It also means that making it easy to connect people together, esp removing friction, makes more of them do stuff together. The massive success of Github vs other interfaces argues my point for me.
“Maybe it would be more if the code was on github”
That’s what I telling you rephrased. Also, expanded to the average project as some will get contributions, some won’t, etc.
-
-
-
Heck even I won’t move off of it until there is a superior alternative, sorry.
-
-
I thought about a project along these lines a while ago. Something along the lines of cgit, which could offer a more or less clean and consistent UI, and a easy to set up backend, making federation viable in the first place. Ideally, it wouldn’t even need accounts, instead Email+GPG could be used, for example by including an external mailing list into the repo, with a few addition markup features, such as internal linking and code highlighting. This “web app” would then effectively only serve as an aggregator of external information, onto one site, making it even easier to federate the entire structure, since the data wouldn’t even be necessarily bound to one server! If one were to be really evil, one could also use GitHub as a backend…
I thought about all of this for a while, but the big downsides from my perspective seemed to be a lack of reliability on servers (which is sadly something we have come to expect with tools such as NPM and Go’s packaging), asynchronous updates could mess stuff up, unless there were to be a central reference repo per project, and the social element in social coding could be hard to achieve. Think of stars, followings, likes, fork overviews, etc. these are all factors which help projects and devs display their reputation, for better or for worse.
Personally, I’m a bit sceptical that something along these lines would manage to have a real attractiveness, at least for now.
-
Lacks a web interface, but there are efforts to use ipfs for a storage backend.
-
I think there have been proposals for gitlab and gitea/gogs to implement federated pull request. I would certainly love it since I stuff most of my project into my personal gitea instance anyway. Github is merely a code mirror where people happen to be able to file issues.
-
I think this would honestly get the work done. Federated pull request, federated issue discussion
-
I’m personally a bit torn if a federated github-like should handle it like a fork, ie, if somebody opens an issue they do it on their instance and you get a small notification and you can follow the issue in your own repo
Or if it should merely allow people to use my instance to file issues directly there like with OAuth or OpenID Connect. Probably something we’ll have to figure out in the process.
-
just make it work like gnusocial/mastodon. username@server.com posted an issue on your repo. You can block server, have a whitelist, or let anyone in the world is your oyster.
-
-
-
-
-
I always thought it would be neat to try to implement this via upspin since it already provides identity, permissions, and a global (secure) namespace. Basically, my handwavy thoughts are: design what your “federated github” repo looks like in terms of files. This becomes the API or contract for federation. Maybe certain files are really not files but essentially RPCs and this is implemented by a custom upspin server. You have an issue directory, your actually git directory, and whatever else you feel is important for managing a software project on git represented in a file tree. Now create a local stateless web interface that anyone can fire up (assuming you have an upspin user) and now you can browse the global upspin filesystem and interact with repos ,make pull requests, and file issues.
I was thinking that centralized versions of this could exist like github for usability for most users. In this case users’ private keys are actually managed by the github like service itself as a base case to achieve equal usability for the masses. The main difference is that the github like service exports all the important information via upspin for others to interact with via their own clients.
-
It’s not. It’s a server software that accesses this network.