staltz

Are you talking about Planetary social?

That's a very limiting definition of 'death' and it may as well have applied for "Linux Desktop", yet Linux as a Desktop choice is increasingly popular, just not at a growth rate that would satisfy Silicon Valley: https://www.justingarrison.com/blog/year-of-linux-desktop/

As for 1: you don't have metrics for that. As for 2: you don't have metrics for that.

It's called "invite" because people invite you, not because you can search for one on the web.

If you don't want to store people's data, then an SSB "room" server is the option, and in fact is the best type of server currently serving the SSB network. More info here https://www.manyver.se/faq/admin-room

(I develop Manyverse) Onboarding in SSB is invite-driven and thus is at odds with safety. If you want to "find people" easily, and easily join the network, then this means that any harasser can also do the same. Improving Onboarding while not sacrificing Sustainability and Safety is my top priority and there are several protocol advancements being worked on, more information here: https://gitlab.com/staltz/manyverse/-/wikis/Starchart/

What makes you think it is dead when there are active users every day, development is active, and there's a developer conference this week (https://p2p-basel.org/)?

Manyverse is cross-platform and it's the main desktop app nowadays: https://manyver.se

The Scuttlebutt.nz website hasn't been kept up-to-date. SSB's development is also decentralized, so this means that not everything moves forward in unison, so depending on who you ask, Scuttlebutt.nz is not the official frontpage.

See https://news.ycombinator.com/item?id=28616361

Manyverse creator here. We're working on the desktop app and it's almost ready. I use it on a regular basis on my own desktop. Check a screenshot and progress report at the bottom of this blog post: https://www.manyver.se/blog/2021-09-update

Hi, I'm the creator of Manyverse. This part definitely needs to be clarified/improved on the UX side, and we know what should be done (we had a UX project dedicated to this: https://www.manyver.se/ux-research/ ) and we'll work on it soonish (still this year according to our roadmap). SSB is an invite-based system, and this is very important for community safety, this is what makes SSB really stand apart as a nice social network.

If you, or anyone reading this, wants to join our community, send me a DM on Twitter @andrestaltz with a short comment on who you are and what you're interested in, and I'll invite you if you seem trustworthy and friendly.

Hi, I'm the creator of Manyverse. We definitely want to be on F-Droid, the reason it's not there at the moment is merely technical. Manyverse is a beast to compile on F-Droid servers, requires compiling Node.js (Mobile) from scratch, compiling several Rust dependencies, C++ dependencies, and it's a React Native project (which comes with its own headaches). Some while ago the build broke and I've been pouring hours into it trying to bring the build back, but it's killing me. Sorry for the inconvenience

Hi! I'm the creator of Manyverse.

That's right, it's using a ton of space. We are currently working on a new protocol extension for SSB targeted at solving exactly this. Here's a presentation from some months ago, https://www.youtube.com/watch?v=LKr208wpr6Y , although our designs have changed a bit during implementation. See also https://github.com/ssb-ngi-pointer/ssb-meta-feeds-spec

We're building this under a grant from the EU Commission, NGI Pointer, read more about it here https://www.manyver.se/blog/2020-10-update

We're almost finished with a proof of concept of meta feeds for partial replication, and we're working on compiling statistics on how much will it reduce the total payload sizes during replication. For that purpose we built a network simulator to simulate replication at scale: https://github.com/ssb-ngi-pointer/netsim/

> Similar can be said from everything like Scuttlebutt to GNU Jami; any service that operates on a P2P basis will likely reveal your IP, and tie your identity to it (and your IP address history). In some cases, as with Jami, this would be limited to friends you add; in others, as with Scuttlebutt and IPFS, it could be revealed to anyone.

Regarding Scuttlebutt (SSB), this isn't quite true. While IPFS requires a DHT, SSB's primary mode of updating content is via servers such as pubs and rooms, the DHT in SSB is optional and not the most common mode of updating content. In SSB you can and should choose the servers which you're connecting to, so in that sense it's closer to the federated model.

It's not entirely fair that the article equates "P2P" to "DHT", there are many ways you can do P2P connections, a DHT is only used for discovery. IP leakage is a problem in all these models (centralized, P2P, federated, etc): some computer somewhere will see your IP address, and you have to trust them not to do bad stuff with it.

For a comprehensive overview of privacy in DHTs and P2P, watch this talk: https://www.youtube.com/watch?v=nCCkwU4JPcY

Interesting tool. It basically says you can:

- Tax coal, oil, natural gas, bioenergy

- Subsidize renewables, nuclear, new technology

- Increase efficiency and electrification of transports, buildings, and industry

- Reduce population growth

- Reduce economic growth

- Reduce deforestation

- Increase afforestation

For an effect that puts us at +2.1C by 2100 https://en-roads.climateinteractive.org/scenario.html?p1=120...

OR you can do these three things:

- Set a high price on carbon

- Reduce emissions of methane and other gases

- Increase usage carbon removal technologies

for a similar effect of +2.1C by 2100 https://en-roads.climateinteractive.org/scenario.html?p39=25...

All optimistic actions combined puts us at +1.0C by 2100 https://en-roads.climateinteractive.org/scenario.html?p1=120...

Very relevant context for what they are looking for can be found not in Jack's thread but Parag's thread: https://twitter.com/paraga/status/1204766188074459136?s=19

This rules out a lot of existing projects. IMO rules out AP, SSB, Matrix, etc

Rooms are decentralized. It's not following the end-to-end principle, because rooms are intermediaries, but there can be many rooms, they are fungible, and they are not hard coded anywhere. It's possible to build similar functionality on a DHT, but it has a couple of downsides:

1. The bootstrapping servers for DHTs are legitimately centralized and hard-coded servers 2. On a DHT you leak your IP address to many other peers, with rooms you leak your IP address only to the room administrator. (This is supposing without an anonymization layer, which would have some non-negligible overhead) 3. Connecting to DHT peers is not as reliable and consistently functioning as a static IP address, considering all sorts of network situations, specially mobile data plans

That said, I don't have anything against DHTs, and in fact I might improve how Manyverse uses DHTs. I just think it's important that users know the drawbacks of each approach, and then users can choose whichever approach fits their needs best. This is why Manyverse focuses on multiple connectivity modes: LAN, Bluetooth, Pubs, Rooms, DHTs. I think the more of these we have, the more resilient the network will be. So my argument isn't for rooms instead of DHTs, my argument is that adding rooms is good to fill in a gap in choices for connectivity.

As I shared with you on Twitter (1), I think the definitions of the terms might have been misleading. For instance, although the charts use the word "salary", in my blog post I defined what those terms meant:

> ...how much yearly revenue for a project goes to each “full-time equivalent” contributor. This is essentially their salary. Or, said better, this is how much their salary via donations would be if they were working exclusively on the open source project, without any complementary income. It is likely that a sizable amount of creators and maintainers work only part-time on their projects. Those that work full-time sometimes complement their income with savings or by living in a country with lower costs of living...

Later, when I specifically mention Electron, I say:

> This doesn’t mean the people working on those projects are poor, because in several cases the maintainers have jobs at companies that allow open source contributions. What it does mean, however, is that unless companies take an active role in supporting open source with significant funding, what’s left is a situation where most open source maintainers are severely underfunded.

In summary, this means that projects categorized in red or orange can be one of these cases:

- Maintainer is an employee earning fair salary, and nearly nothing (<10%) from donations: Electron et al

- Maintainer is independent, earns significantly (>50%) from donations: Sindre Sorhus (AVA), myself (Manyverse and Cycle.js), Paul Frazee (Beaker Browser) and others

- Maintainer is independent, earns entirely from donations: Titus (Unified) and others

The core message of the blog post still stands true, unless companies take a central role in sustaining open source (which is your case!), what's left is a situation of unfair compensation to open source maintainers.

[1]: https://twitter.com/andrestaltz/status/1139533257077338112

> How are the Electron project creators and core contributors not 'the core persons involved in open source'?

I didn't say that and would not have agreed to saying that.

Notice what I did say, though:

> "Unless companies take an active role in supporting open source with significant funding"

When a company has employees working on an open source project, such as Electron, that is an active role in supporting open source.

There are different projects, some are internal company infrastructure that was open sourced (React, Electron, Angular, etc), and some are built by hobbyists/indies (Unified, Prettier, Core-js, etc). Companies definitely take a good active role in the first type, and less so in the second type. However, quite often there are projects of the second type being used as dependencies in projects of the first type, as well as in proprietary software, of course. This is why I raise the need for even more company active involvement in open source. It's more about requiring their participation in the culture of gifting (because open source is a commons), than it is about requiring specific donations on specific projects on a transactional basis. In my article I address why companies typically don't participate in open source commons: because companies have a financial brain that guides them towards profit and competitiveness, not gifting. This is why we must "rewrite some rules of society".

Yes, and what I meant by exploitation is this: open source is a culture of gifting, either in the form of new projects, or pull requests, donations, or other forms of volunteering. Companies (not all) quite often consciously do not participate in that culture, but still use the code and community to create their surpluses.

On Electron, I wrote this in my article:

> ... such as Prettier, Curl, Jekyll, Electron. This doesn’t mean the people working on those projects are poor, because in several cases the maintainers have jobs at companies that allow open source contributions.

Then,

> Why you compare GitHub's acquisition price to the amount of money being put into open-source instead of seeing it as money being put into open-source is beyond me.

Because Microsoft, as a public company, cannot make an acquisition the size of 20% their profit that year without a clear plan for ROI on that cost, and this will likely happen through some integration with Azure, since the GitHub CEO reports to Microsoft's VP of Cloud and Enterprise. And even if GitHub is seen as a platform that supports open source (therefore money into the platform being a positive for open source), it is weird and unfair for a support partner to earn significantly more money than the core persons involved in open source.

Author here. Actually I did mention in the article that company time was a good option:

> This doesn’t mean the people working on those projects are poor, because in several cases the maintainers have jobs at companies that allow open source contributions. What it does mean, however, is that unless companies take an active role in supporting open source with significant funding, what’s left is a situation where most open source maintainers are severely underfunded.

I see you have not met substack, Dominic Tarr, myself, Titus, and others. Here is substack's lifetime earnings: https://twitter.com/substack/status/829802572508639232 This Twitter thread is also quite on topic with your comment.