1. 9

    Is this finally how we get Java as the one true language platform we were promised in the 90s? Java -> WASM. What a world we live in.

    (Only half being snarky here)

    1. 4

      Google already wrote a java->js compiler a long time ago. I think parts of gmail etc were written in java for a long time if they aren’t still.

      1. 3
        1. 2

          And the GWT replacement, J2CL

    1. 28

      As much as I believe every single last person involved in cryptography yelling “use Signal”, it doesn’t fit everyone’s use case of a chat application.

      Signal has a hard requirement that you give them a mobile phone number to tie to an account and register from a smartphone. This number is also exposed to other contacts. As for the alternatives in the article, namely: Wire has monthly fees that may prove difficult to pay anonymously. WhatsApp is owned by Facebook; even if you consider this okay enough somehow, that still requires you to go through your smartphone, on which it requires a phone number for registration; not that you could install it on an OS that isn’t macOS or Windows anyway.

      People may suggest to “just get a burner SIM”. But that is not a reasonable option if your goal is to hide your real life identity: For example, in Greece and Spain, you must provide ID and formerly anonymous SIM cards were blocked see COM(2010) 253, p. 69. That’s a non-starter in these scenarios. Of course, you may still argue that people that need to go to such extents to hide are almost certainly criminals, terrorists or dissenters (none of which may be worth protecting depending on your morals), and you’d probably be right. Nonetheless, the increasing disappearance of an untied, non-real-life identity scenario is a worrying prospect to me.

        1. 5

          Read to the end of the article, where Signal clarifies that they don’t consider it a problem because the goal was never for Signal Desktop to provide at-rest encryption. (I will say however that I too have always wondered why they bothered using SQLCipher to begin with.) If you need that, use full-disk encryption. That will protect you much better.

          “But they should be aiming for at-rest encryption.” Let’s play this out:

          1. The only way Signal Desktop can accomplish this without some additional support from the platform*, AFAICT, is to require a decryption password that the user types in at startup. Already this breaks a lot of useful things: it breaks the ability for the app to autostart when the user logs in, and that means that if the user forgets to type in the password (and they will) notifications for new messages won’t work, silently. So already we’ve seriously broken the UX.
          2. The decryption password can’t even be secured properly. A malicious app on your system can just sniff the keystrokes. Or, it can just record the screen. AFAIK Windows and macOS don’t restrict these operations by default (maybe keylogging, but I’ve never gotten a prompt or anything for screen recording IIRC). Wayland on Linux is supposed to fix this but adoption is “in progress” at best on that front so that doesn’t do us any good.
          3. Let’s say that isn’t a problem. Maybe something changed since I used Windows or macOS and they’re better now. The password still isn’t secure. Your disk isn’t encrypted so the attacker can tamper with the Signal binary if they have physical access. Now Signal is malicious. Game over.
          4. But let’s say that the attacker doesn’t have physical access, and you’re sure all the apps on your system are trustworthy. Are you sure they don’t have a security vulnerability and won’t get compromised to sniff your Signal password?

          The list goes on. This can’t be mitigated at the app level because the platform is fundamentally not designed for this. Mobile devices isolate apps by default; you don’t routinely run processes that aren’t sandboxed. But on desktop, the opposite is true. There are valiant efforts to sandbox apps, like the Mac App Store requiring that all apps distributed through it enable sandboxing, and Flatpak on Linux. But those are still opt-in. Are you sure that everything on your system is sandboxed enough? To actually guarantee this, you need something like Qubes.

          Signal Desktop absolutely has problems… but I don’t think this is one.

          [*]: keyrings have this same problem. Usually they’re unlocked automatically on login, so any unsandboxed app running in the user’s session can just ask the keyring to give it the Signal password. At least AFAICT… I vaguely recall macOS having some sort of access control.

          1. 2

            The core premise of the article is completely mistaken. The database key was never intended to be a secret. At-rest encryption is not something that Signal Desktop is currently trying to provide or has ever claimed to provide. Full-disk encryption can be enabled at the OS level on most desktop platforms.

          2. 8

            I definitely agree that, when possible, people should avoid communication tools that require phone numbers and use something like XMPP with OMEMO instead.

            If you do need/want to use Signal or similar, there are phone number options that let you maintain anonymity. For example, https://jmp.chat/ gives you a Canadian or US number without requiring any identifying information (you can even signup over Tor). If you want to keep the number past 30 days, you can pay in Bitcoin Cash or Bitcoin, or use https://shapeshift.io/ to pay with other more anonymous cryptocurrencies.

            1. 8

              Yep. I use Signal extensively in my labor activism. This is an example of an activity which is entirely legal in the United States, but where I am putting people in danger simply by talking to them. I agree 100% with all your criticisms, and it’s quite unfortunate that there are many situations in which there isn’t a realistic alternative.

              1. 2

                Is there at least groundwork for such an alternative to Signal that doesn’t require a phone number? I’m in the same situation.

                1. 1

                  The protocol is open, although it’s my understanding somebody would need to do a lot of implementation. I’d also suggest that future work should be based around expecting users to explicitly manage their keys, rather than trying to abstract that away.

                  1. 2

                    I’d also suggest that future work should be based around expecting users to explicitly manage their keys

                    Why? To me this is the main selling point of Signal. And from my observations teaching PGP (long ago), key management is one of its biggest downfalls.

                    1. 1

                      Sure. It’s because the automatic management both introduces insecurities, and makes it so that good key-verification practices are more friction than sloppy practices.

                      The most significant insecurity is that anyone with control over your phone number can gain control of your account. A stolen SIM or a number-porting attack could both be used that way. They won’t see message history, but they’ll be able to impersonate you. The only defense against this is that there’s a small notice in each chat about the safety number being reset.

                      The point about safety numbers dovetails with my larger point about good practices being hard. When you’re scaling up a large organization, educating everybody about what the safety number means and how to verify it is a constant undertaking. Meanwhile, people are constantly replacing their devices, accidentally reinstalling the app, intentionally reinstalling the app, etc for a variety of reasons. It’s constant tedium, and if you just punt on doing the work, there’s a chance of an impersonation attack being successful.

                      What I would like is to put key management front and center, so that everybody gets the message that this is something they should be paying attention to and learning more about. I’m envisioning, for example, a first-start wizard that walks users through creating an offline key and using it to sign a per-device subkey, with alternatives also presented if they want to add a key some other way. Yes, it’s a lot of work which would slow down adoption immensely. Thus, I don’t realistically expect any for-profit entity to be the first to offer a product that works this way. Still, in my ideal world, it’s what I’d like to see.

                      1. 1

                        Hm. So if I can rephrase this position, basically you’re saying that good practices (i.e. verifying safety numbers) isn’t on a level playing field with unsafe practices, because it’s much easier to do the latter. And basically you want to level the playing field by making both take equal amounts of effort? Did I get that (somewhat) right?

                        1. 1

                          I think that’s right, yes. I know it’s in some ways a quixotic idea.

              2. 6

                I use Signal constantly, but this is a sound comment and still only covers maybe half the serious concerns I have with Signal.

                1. 2

                  We are pseudonymous in Peergos (no phone number or even email required to sign up). At the moment we are focussed on storage and sharing, but we plan to implement a group chat/messaging solution using Messaging Layer Security once it stabilises.

                1. 3

                  First paragraph is wrong. You can simulate a quantum computer on a classical computer. It’s just much slower.

                  1. 5

                    I have a few questions I’d love to know about Matrix:

                    1. Can I run a matrix server in my house if it is behind a NAT?
                    2. Do I have to have a domain name if I want to run a server?
                    3. Am I able to change the domain name of my server without breaking my account?
                    4. Is there a statement anywhere of exactly what information is public, like the source and target of each message. What I want to know is what metadata is public (also with encryption enabled)
                    5. Is it possible to backup my data elsewhere such that I can restore my identity and social connections to a new server if the old one shuts down suddenly?
                    1. 7
                      1. Yes, but you would have to enable port forwarding. For carrier-grade NATs you might need something like a WireGuard VPN to publicly expose your server.
                      2. Yes, using an IP address is only supported for development purposes, don’t do this in production.
                      3. No, when MSC1228 is implemented this will be possible. But I assume that won’t happen too soon. While you currently can’t change the domain that is included in your identity (@user:example.org) you can change the domain where your server is running. E.g. your username can be @user:example.org while your server is running at matrix.example.org. This is documented here. You can later change the domain where your server is running, but the domain in your username is fixed. I would recommend not to include a matrix.-prefix in the username domain.
                      4. If e2e-encryption is enabled in a room, all content (text messages, images, files, one-to-one voice calls) is encrypted end-to-end. Room membership, permissions and invitations are visible to the adminstrators of the participating Matrix servers. Integration stuff like group voice conferences via Jitsi are visible to the server administrators of the integration server (which is usually vector.im).
                      5. You can do regular backups of the database and the media directory, as long as you keep control of your domain you can spin up a new server and just restore the data.
                      1. 1

                        Thanks for your answers MazeChaZer!

                        A few clarifications: for 4 I’m interested if there is any effort to hide things like message sizes, file sizes, file names. How is the membership list restricted only to participating matrix servers?

                        For 5 I’m talking about the situation where my hosting server shuts down (say I’m using a service that decided to shutter). Am I able to restore my backup on another server? It sounds like the answer is no. Which means that to be safe you should never sign up with a domain name you don’t control. Could you set up you own domain name and point it to another matrix server’s domain which you don’t control and sign up that way?

                        1. 1
                          1. I’m not aware of any efforts to hide message or file sizes. But the file names should be encrypted as part of the message content. Membership list is restricted to participating servers because you can only access the membership list if you’re part of a room. Federation doesn’t mean that every bit of available data is publicly exposed.
                          2. Yes this is correct, I recommend that you get your own domain name. Then you can use the domain you control for your username and the hoster domain that you don’t control for the server itself. On how to connect these domains see the federation doc I linked above.
                    1. 1

                      About your problem of not having writablestream available on firefox, maybe you can use serviceworker instead.

                      1. 1

                        Thanks for your suggestion. We’re already using service workers, but that’s not sufficient to download a file larger than you can fit in memory. As far as we’re aware there is no solution other than writable streams. For more information see https://github.com/jimmywarting/StreamSaver.js

                        1. 1

                          I eventually understood.

                      1. 1

                        for others, who like me were not familiar with the tool, I found this brief intro useful:

                        “… You can think of Peergos as a cross between Dropbox, email, Facebook, YouTube and Twitter, but fully end-to-end encrypted and decentralised to keep your data and social graph private. … “

                        http://book.peergos.org/

                        My questions for @ianopolous would be

                        a) can I use the technology without singing up for anybodys’s central service

                        b) can I host some content (eg my resume) on my mobile phone (android), and what would happen when phone is off (eg, is there caching?) , if not there yet – is that planned?

                        c)how can my resume (as example noted in b) can be discovered/searched by others

                        d) can it be deleted? forever?

                        e) I did not know fully understand appreciate the social network aspect – is that like mastodon or something else?

                        thank you for sharing

                        1. 1

                          Hi vladislavp,

                          Thanks for your questions. Yes you can self host Peergos and then your instance will be responsible for storing all your data. When you sign up you communicate with a global pki to claim your username. We chose the UX tradeoff there because that’s what people are used to.

                          Currently there isn’t any guaranteed caching (though if someone else views your file, ipfs should cache it on their instance temporarily. Longer term we hope to let you mirror your stuff on your friend’s nodes.

                          Only people who you grant access (read or write) to a file can see it. You can also create a public link to a file which anyone can use to view it, without needing to install or sign up to anything, e.g.: https://demo.peergos.net/#6MDZhRRPT4ugkJuUfcPPhf1US9u7FvRALmj42mJ6e3yDibnLtqfhchE6Frm6Lf/6MDZhRRPT4ugkJuUfcZdxu6JLKyrLBE36Kasxb4jix7An4dbeiekpDF6h2fDBM/HUja6zmXVs24zcRf15s1MWB7kfvyTCp2X9NF4EZqcw7/5Pf7SvCKyBYfP1vm5LfTSw8TMHtLWvJDLv1P4QtCXV8P2Zv8FwR

                          You can delete your files yes. That was a core requirement. It should behave like a global filesystem.

                          At the moment the social side is quite primitive, you can share files and folders (read only, or writable) with other peergos users who follow you (and revoke said access, which means rotating keys and re-encrypting). We plan to add many-to-many messaging ala Signal, and later a more traditional social feed as well. The whole thing is independent of DNS or the TLS certificate authorities (unless you choose to use a public web interface) so there’s no need to get a domain name and manage all that complexity if you want to run your own instance. (You can access your instance from elsewhere still without DNS or TLD using ipfs’s p2p streams which are E2E encrypted independently).

                        1. 2

                          Now that the Peergos alpha is released I can chillax a bit. That means gardening and enjoying the sunshine mainly.

                          1. 3

                            We’ve been working on this in our spare time for 5 years now. Super excited to hear what people think.

                            1. 2

                              It would be amazing if Firefox can implement writable streams: https://bugzilla.mozilla.org/show_bug.cgi?id=1474543

                              Given our privacy focus, we’d love to recommend them, but currently can’t. This is critical for streaming large amounts of client generated data (in our case locally decrypted)

                              1. 1

                                Could you folks implement them or is that too far outside the scope of your project to make sense?

                                1. 2

                                  If we had the resources I would happily volunteer us, but as it is we already work on Peergos for free in our spare time.

                              1. 6

                                Did you try using zgc or Shenandoah? Either of those would get you max gc pauses ~1ms. For startup time and ram reduction you can also consider graal VM native image, which AOT compiles your code so there is no JIT and no associated warm up and ram usage.

                                1. 1

                                  For those that can’t justify a port, there’s also commercial VM’s that are high performance and/or real-time. Old favorite (pdf). Java performance != OpenJDK performance even though that’s the default in many people’s minds. There’s a few implementations with different properties.

                                1. 4

                                  I don’t think anything you want implies public key cryptography. And that actually opens up a new vulnerability to quantum computers when they arrive. You can do it all with symmetric encryption and hashing, neither of which is vulnerable to quantum attacks.

                                  This is the technique we use in Peergos.

                                  Initial key derivation: https://peergos.github.io/book/security/login.html

                                  and subsequent access control with cryptree: https://peergos.github.io/book/security/cryptree.html

                                  cryptree paper: https://github.com/Peergos/Peergos/raw/master/papers/wuala-cryptree.pdf

                                  1. 1

                                    I had thought previously about the idea of a master symmetric key and subordinate device keys. It is worth thinking about, thanks for the links.

                                  1. 4

                                    It was great talking at the Decentralised Web Summit, and the IPFS Lab Day last week. I’ve just finished moving the Peergos PKI into IPFS itself, and this week I’m hoping to make that pki mirrored on every node (for privacy of key lookup queries). And think more about improving the scalability of the social side of Peergos.

                                    We also want to implement a new api call in IPFS which I dicussed with them last week - essentially a p2p http proxy (independent of dns/ip).

                                    1. 10

                                      Neat surprise, I maintain this (and similar) pages. Originally started because I wanted to show de-facto support for modern crypto but now I refer back to the pages as a starting point in choosing software that does one particular task or another. I think modern crypto has basically “won” even if there are still gains to be made. One thing I’ve noticed is that the de-facto support goes way beyond de-jure support to a degree that looks suspicious for standards bodies. It’s been the main factor in convincing me that standards bodies need to be taken down a notch – let’s have more public competition and less “design by committee.” I think the community is moving more in that direction and it’s good to see.

                                      There are over 1700 unique outbound links on these pages. I scan their http status codes with automated scripts several times a week and make other efforts to prevent link rot and outdated info. It takes a surprising amount of time. For instance some people say they support a cryptographic primitive but you look at the code and it’s something else, so you have to check, and it takes time. Good example of the importance of useful, correct documentation.

                                      Minor thing I noticed: a handful of github pages were deleted after the Microsoft purchase, but not as many as one might have expected based on public discussion. Now that things have settled I’ll check each one manually to look for “page moved to gitlab” type messages where the github repos remain with http 200 status codes, but emptied out. It takes a lot of time to maintain these pages but it’s helped some people so it feels good.

                                      1. 3

                                        Yea it was a quite awesome link, and seeing i2p in it warmed my heart<3 (disclamer; I’m a i2p dev)

                                        1. 2

                                          Was pleasantly surprised to see Yggdrasil, a project I work on, listed there too!

                                        2. 2

                                          Not sure if you’re aware but the font size on that site is absolutely huge on Chrome on Linux. I have to dial it down to 67% the original size to make it readable. Here’s a screenshot to illustrate, with lobsters for comparison: http://i.imgur.com/4I8eegV.png

                                          1. 1

                                            Thank you for the feedback! Yeah, font size is an issue these days and it’s something I’ve wrestled with. A while back there was an article about how font sizes haven’t kept pace with monitor / screen resolution increases, which I think is hard to disagree with. The situation is compounded by the large variety of “monitors” from phones to what amount to widescreen TVs. If you have a simple suggestion for HTML/CSS that doesn’t use any JS and makes everyone happy I’d be very interested in hearing it.

                                          2. 1

                                            Thank you for all your work! I’m pleased to have two projects in the list. I wonder if there will be an equivalent for post-quantum crypto once the algorithm advice stabilises.

                                            1. 1

                                              Yes, there already is a pqcrypto list but it’s kinda shabby IMO (check the links under the homepage). The pqcrypto situation is very fluid at the moment, even chaotic. As one example of many, the front-runner library is libpqcrypto which contains 77 cryptographic systems (50 signature systems and 27 encryption systems). There are more post-quantum algorithms than apps using those algorithms. Also libpqcrypto doesn’t even compile on OpenBSD, a bummer for me personally. IMO for certain things like VPNs, combining an ephemeral X25519 key exchange with a pre-shared key, like WireGuard can optionally do, is a sensible thing to do in 2018 until we get real pqcrypto off the ground.

                                          1. 6

                                            I’m working on moving the central PKI in Peergos from sqlite to ipfs itself. We’re using a champ (compressed hash array mapped trie) - the same data structure which we’ve already migrated all user data to. It has a lot of nice properties, like insertion order independence and fast lookups.

                                            This will make mirroring the PKI trivial, and allow private public-key lookups on the mirrors.

                                            1. 15

                                              “Operating system design has been somewhat stagnant since, well, ever. Sure, once in a while, you hear of a cool os that some company worked on ten years ago or an interesting prototype that has recently crawled it’s way out of a professor’s underground lab”

                                              There’s probably several a year at a minimum. Almost all are made by CompSci but companies do stuff too (eg Fuchsia). I stopped tracking them since there were too many with a lot of duplicated capabilities (esp cloud stuff). If you liked Singularity, you might find SPIN, J-Kernel, JX, Verve, and ExpressOS interesting.They all use a type-safe language with simpler architecture. High-assurance security mostly went with microkernels and separation kernels with Nizza paper explaining the concept nicely. GenodeOS takes that approach. Finally, there were also high-assurance, browser architectures and OS’s like IBOS that shared a few goals such as portability with Javascript support.

                                              Hope you enjoy some of this stuff as you think about OS design. And welcome to Lobsters! :)

                                              1. 3

                                                G’day Nick, Have you looked at redox at all? Also in a similar vein, but in Java and not developed any more I think, is jnode.

                                                1. 2

                                                  Both Redox and Muen separation kernel could be on the list. JNode was neat but I didnt evaluate its security. JX had neat architecture.

                                                  1. 2

                                                    Jnode was trying to run legacy x86 software with my very own jpc.

                                                    1. 4

                                                      If you like those, check out sanos. It’s an older one with a Windows focus few seem to know about.

                                                1. 1

                                                  Yeah, but mostly for their core stuff.

                                                  1. 1

                                                    I missed that constant-time performance comment - which is very helpful, but wish it was called out a little more explicitly. I wish the memory/runtime complexity were called out as explicitly as the load factor that is liberally sprinkled throughout.

                                                  1. 21

                                                    This is a beautiful technology. It is very sad that many people will ignore this because of Oracle v. Google lawsuit. What a tragedy.

                                                    1. 15

                                                      This looks suspiciously like an “embrace, extend, and extinguish” play by Oracle to the observer.

                                                      1. 16

                                                        Anything from them potentially is one just due to their legal team. I’m avoiding it specifically for that. Java, too, just in case.

                                                        1. -1

                                                          It’s all open source.

                                                          1. 4

                                                            That’s copyright law mostly with patent provisions in some licenses for the specific work as is. That leaves patents for how it’s used or combined with other software. Oracle, Microsoft, and IBM in particular like to file lots of those. I dont know if any are on GraalVM because just looking triples the damages. I never look.

                                                            1. 2

                                                              I’m not a lawyer, but openJDK, which now includes Graal, is GPL licenced which includes patent protection.

                                                              1. 1

                                                                This is incorrect; the patent grant applies to the official OpenJDK builds but not forks of OpenJDK.

                                                                1. 1

                                                                  Do you have a source for that? That wouldn’t be GPL then under my understanding.

                                                                  The GPL seems relatively clear on this: http://openjdk.java.net/legal/gplv2+ce.html

                                                                  1. 3

                                                                    If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

                                                                    Seems to me that the patent clause is opt-in rather than required. OpenJDK uses the GPL v2, which lacks the clear patent grants of v3.

                                                                    See also https://www.skife.org/java/jcp/2010/12/07/the-tck-trap.html and the lawsuits Oracle fired at Google. (The patent claims ended up getting thrown out because Google has excellent lawyers in that case.)

                                                                    Edit: more details about the weak language used around patents in v2: https://www.infoq.com/articles/java-dotnet-patents

                                                                    In 2004 Dan Ravicher, senior counsel for the Free Software Foundation, warned about the weak patent guarantees for BSD and GPL and recommended attaching patent grants.

                                                                    1. 2

                                                                      With further digging it seems that Oracle joined the OIN and OIN explicitly covers the openJDK for patents:

                                                                      http://www.openinventionnetwork.com/community-of-licensees/

                                                                      https://www.zdnet.com/article/linux-patent-defense-group-expands-open-source-protection/

                                                                      1. 2

                                                                        Thank you. That is very interesting reading. Sounds like the waters are muddy and we need an actual lawyer to chime in.

                                                                        I partially side with Oracle on the Google case (excluding copyrighting APIs). Google had plenty of opportunity to licence Java from Sun, or indeed to buy Sun entirely, but they chose to incompatibly re-implement it and developers have been paying the price for that choice ever since. But it looks like Google finally did the right thing in the end: http://www.fosspatents.com/2015/12/google-switches-to-open-source-license.html

                                                              2. 1

                                                                Not all of it. The GraalVM Downloads page makes it clear that there are two versions of GraalVM: Community Edition (CE) and Enterprise Edition (EE). GraalVM EE is closed-source, and it’s the only version with support for macOS and with “additional performance, security, and scalability”.

                                                                1. 1

                                                                  The developers have stated the only reason for the macos absence is they haven’t gotten around to it yet, and also there is currently no difference in performance.

                                                          1. 3

                                                            This should prove to be a very attractive alternative to Electron when coupled with JavaFX.

                                                            1. 2

                                                              I don’t see how. Whole point of Electron is that you can reuse your web frontend knowledges. JavaFX does not allow that. (I guess JavaFX does allow styling with CSS, albeit with hideous fx prefix.)

                                                              1. 2

                                                                I have done exactly that. JavaFX also has WebView component. Under the hood I believe it currently uses v8, but it sounds like they can switch that out with Graal.

                                                                1. 1

                                                                  That’s part of the point, but a big part of it is also just targeting all 3 platforms with one codebase.

                                                              1. 2

                                                                The e2e encrypted chat has a subscription model. I wish this were the private communication platform it claims to be. The closest we have now is keybase, which is not optimal either

                                                                1. 1

                                                                  A subscription model itself is not bad. But if they are selling themselves as a private communication network, it’s strange that the only privacy friendly piece is the one that costs extra.

                                                                  1. 1

                                                                    I’m interested in your opinion on the deficiencies in keybase. What features would you change or add?

                                                                    1. 2

                                                                      If I were to introduce keybase as a communication platform for my less tech interested friends and family, it would have look more like what MeWe looks like. A chat/social network/shared photos.

                                                                  1. 8

                                                                    The only shot these decentralized networks/social things have of accomplishing their dream is to ditch federation and deploy true P2P via desktop/mobile apps. Think old Skype.

                                                                    Any server requirement more than a non-proxying NAT hole puncher is a death sentence for decentralized services targeting mainstream users (unless you get big investments into a handful of quasi-centralized servers). The network needs to run on a handful of techie users fronting $10/month in server resources, or it just won’t scale.

                                                                    People can install apps, they can’t manage servers.

                                                                    1. 7

                                                                      People should just implement these things using email as the communication substrate. The servers are already out there and federated.

                                                                      1. 1

                                                                        This is the conclusion I came to as well. The “liked by who” is metadata that would have to be stored somewhere though.

                                                                        1. 1

                                                                          That can be sent around via email as well. Likes can be implemented as a CRDT, so people may not have a consistent view but it can become consistent over time.

                                                                        2. 1

                                                                          If you’re emailing your friends then you’ve immediately exposed your social graph.

                                                                          1. 1

                                                                            You don’t have to use their personal email addresses, they can create free ones on gmail or wherever. I’m just saying to use email as the underlying protocol.

                                                                            1. 1

                                                                              That doesn’t help. Even if it was a randomly chosen email, the sender and receiver are in the clear for the network to see and construct the social graph. Even if you rotate emails it’s probably still reconstructible.

                                                                              1. 1

                                                                                Sure. If that’s something you want to hide then maybe that’s a problem for you.

                                                                        3. 4

                                                                          Not all federation has expensive costs. Pleroma can run on a raspberry pi. The Pleroma/Mastodon/GNUSocial is around a million users right now, so I’m not really sure that argument holds. Being said I would also love to see “Old Skype” apps. Ring.cx is a good example of this working well. Decentralization and Federation don’t have to be mutually exclusive and we should stop thinking about this space as an either / or.

                                                                          1. 4

                                                                            This is the approach I took with Firestr, Just download the app and run it. Only server thing is a non-proxying NAT hole puncher. I took this approach because that’s exactly what i thought, no user is going to run a server, therefore has to be an all in one experience where you just run the app and go.

                                                                            1. 2

                                                                              Isn’t Skype a bad example for “true decentralisation” (I am assuming you mean by this “distributed”), since a cenral server managed usernames, statuses and IP address communication (if I am not wrong)? Attempts to truly create P2P networks, lets take the standard example of IM/video chat, like Tox suffer from cryptic user names (ie. DHT codes), the need for both parties to be simultaneously online for messages to be sent and received and most of the time a “hacky” feel to the whole setup. The last issue could be avoided by good cooperation between a design/UX/UI and developer team, but I don’t see any way around the first two, without setting some absolute standards (eg. reference servers).

                                                                              It works for certain use cases, for example firechat for physically manifested crowds or Tox for absolutely anonymous chat, but this doesn’t do what most people want, which has sadly always been what centralized systems are intrinsically good at: deferring responsibility to validated identities, transmit information and guarantee/promise operation from the users to some other instance, which is usually legally bindable.

                                                                              1. 2

                                                                                I 100% agree. This is the approach we’ve taken with Peergos. You can create your account by running the desktop version, or you can sign up on our central server (or anyone elses), but your identity, social graph, etc. has nothing do do with that choice of server. All that decides is where, initially, all your data is stored. Through the magic of IPFS it’s accessible from anywhere - we only need at least one server to store each users files to guarantee no loss.

                                                                                Moving an account you created on our server to your own (desktop or cloud instance) is trivial and doesn’t lose any data, metadata or social connections. This gives both a nice on-boarding experience, and also allows us to satisfy a wide range of threat models. The average user can just log in to a server via a web browser exactly like facebook. More discerning users can run their own server, in the cloud or at home.

                                                                                1. 2

                                                                                  True P2P generally isn’t too friendly with battery life and data caps.