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.

Author here. "People writing open source software are not being exploited." Well, I got the curiosity to check the data after having just met with people writing open source software. So I think if you make that claim, you should back it up with at least non-zero evidence. I have done my part.

makes no business sense to do so

Actually it's not true that local-first software cannot be businesses (or non-profit orgs but still revenue-generating), it's just that the money to be made in local-first is an order of magnitude (at least) smaller than with cloud software. On one hand, the money to be made is much smaller, but on the other hand, local-first is where the next big disruptions can happen, while still having a non-zero revenue. Look at open source or open data projects for some examples on this: Wikipedia, VideoLAN (VLC), OpenStreetMaps, etc.

In SSB, pubs seem like an essential (and flawed) part of the network, and this may be true at the present time, but not forever. I'm working on a few alternatives to pub servers, one of them is a server that has no storage of data, it just acts as a meeting point for clients, and sets up tunnels between them. The other is a 1-feed pub, where the idea is to setup a mirror for your data in case you are a feed that has many thousands of followers. In both cases I want to make it easy (as in Heroku one click installer button) to start a server. The idea is that the easier it is to start a server, the more servers there will be in quantity. Off from the internet, SSB already has good mechanisms for sharing data (Wi-Fi and Bluetooth), which other protocols don't seem to have. Its hard to grok how good this is unless you're living in poor internet environments. SSB on the internet is not as well designed as SSB off the internet.

Yes, I've been without using Google Search for more than 2 years. I'm using DuckDuckGo, and honestly very satisfied with it (I particularly enjoy using `!` shortcuts, like !w or !d).

Also have stopped using: Maps, Docs, GMail, and other small services. Google domains and subdomains are blocked in my /etc/hosts file.

The one exception is YouTube. It's hard to replace that one, although I sometimes consume it through HookTube or even DuckDuckGo.

The other half-exception is Android, although I have rooted it, removed Google Play Services and Google apps, and also blocked Google domains in /etc/hosts. I don't know if that counts as "quitting Google", but I feel like it does.

And occasionally, it's impossible to avoid Recaptcha, so I have to sometimes unblock Recaptcha domains in /etc/hosts, pass their obnoxious test, then reblock it.

Honestly, it's much easier to quit Google services than it is to quit Facebook services. The latter has network effects and social pressure, while the former is just a well built free service monetized through surveillance capitalism. Note: I have also quit using any Facebook services.

One very basic value proposition of decentralization for consumers in the context of the internet is offline usage. When you're in an airplane, that's when the need to have the capability at the end device becomes most obvious, and decentralization directly fulfills that need.

OP used an argument I see too often: that the (current) market success of centralization is evidence of centralization's superiority with consumers. For instance:

Open platforms can’t win by directly appealing to users on philosophical grounds, or even cost (see Linux on the desktop). Mainstream users have no good reason to directly interact with blockchain technology—or any piece of code—without intermediaries involved. Openness and decentralization matter to _developers_.

I think both centralization and decentralization can appealing to consumers, depending on the case and on zeitgeist.

For instance, personal computers were decentralization of computing power, back in the days when the Mainframe (centralization) was dominating. Apple is a decentralized computing company. Often decentralization can become businesses through products, read more https://staltz.com/layers-of-the-internet-economy.html

There are also other "stealth" success examples of decentralized software and protocols that are directly appealing to consumers, such as the Camera and Gallery apps on smartphones and the use of JPEG (open standard) and Bluetooth (open protocol) to create (offline-first) and socially share pictures.

The problem with "decentralization" in 2018 is that it was a buzzword related mostly to blockchain technologies, and software built with those were often shadowing and imitating the recent success that tech giants have accumulated. But decentralization goes way back and its success cases are so ubiquitous that we take them for granted and leave them out of the discussion.

It would be like an Observable, where the Observer's next/error/complete are changed from X=>() to X=>Promise where the Promise indicates the Observer is done with the consumption, telling the producer that it can continue producing more values.

Author here: the inspiration for this article came primarily from Erik Meijer and this talk https://www.youtube.com/watch?v=sTSQlYX5DU0 where he talks a lot about Getters and Setters in Scala, although he's not focused on Scala (Erik has worked on C#, Haskell, and is now working on a new PHP-like language at Facebook).