1. 3

    Company: Picnic

    Company site: https://picnic.chat

    Position(s): Senior Software Engineer

    Location: London, UK - onsite or remote (±5h of GMT+1) - we mostly work remote, but also meet in the office for strategy/planning/workshops that make more sense in person.

    Description: Our friends matter to us more than we think. The quantity and quality of our friendships has a bigger influence on health, happiness and even mortality than anything except smoking. At Picnic, we believe the platforms that house these relationships today fall seriously short. Nowhere is this more true than group chats. We’re building a next-gen social app, powered by group chat, to give friends the kind of online space they deserve.

    We’re still pre-launch, so check out our about us page for more details about the product, team & funders.

    Our engineering team (led by me) currently consists of 3 people, so you’ll have major impact from day one.

    Tech stack:

    • TypeScript everywhere
    • React Native for our app, MobX (& some RxJS) for state management
    • Node.js server-side with Express & RSocket servers
    • PostgreSQL as our primary data store
    • SQLite for on-device storage & caching
    • Redis for caching & pubsub

    More details and reasoning behind these choices here.

    Contact: Our hiring process is described in detail on the job spec, but feel free to reach out to me directly on here or harry@picnic.ventures :)

    1. 1

      I was interested in the various links, but the ones to notion (e.g. this one) all 404 for me. Do I need a notion account to view them?

      1. 3

        Ah, my apologies! Here are the public links:

    1. 3

      At first glance, this looks similar to https://cycle.js.org which has a similar concept of drivers. I’ve written one app with Cycle, and I really enjoyed the experience. The biggest issue I found was that some DOM APIs really don’t fit the functional reactive model. What is extremely nice about this model is that all data-flow is explicit and “static”: your code really becomes a description of all the ways that data flows around the app, which is really cool.

      What I don’t get is why this library needs to define its own view templating language, as it seems only superficially different from say JSX? Haven’t looked very deep so I don’t know if it’s essential. This is something that Cycle is very unopinionated about, which is nice.

      1. 1

        Cycle.js looks super interesting. But it looks like it’s at least 10x the size of this. So even if it’s just a more compact implementation of cycle.js, that sounds promising.

        1. 3

          It’s similar to Cycle, but it isn’t based on the concept of streams. Instead, an application is just a function of driver inputs and returns driver outputs.

      1. 1

        Interesting, especially since many of the points and ways to phrase concepts aren’t just the same thing one keeps reading about all the time. But this confused me even more when it came to Endofunctors. How is “Int -> Int” and “Int -> String” an Endofunctor. Aren’t “String” and “Int” two categories?

        1. 3

          Well, you can choose to define a category with the elements of Int as the objects, but I don’t think that’s what’s meant here. I agree that the slides are very confusing. I think the strange notation Int => String here denotes an example mapping from the object Int to the object String (supposedly in some category with types as the objects…). I think that slide doesn’t contain any useful information.

          1. 2

            Functors in most programming languages are all endofunctors because most programming languages are in the category of Types

            (slide 17)

            For example, in Haskell all types and functions are in the category “Hask”, where the objects are Haskell types and the morphisms are functions, identity is the id function and composition is function composition using the . operator. (see here)

            Hope that makes sense :)

            1. 4

              And Hask is only a category if you wave your hands a bit and ignore seq and bottom. But it’s good enough as an intuition pump.

          1. 7

            But—think about this: I don’t have to take on cloud hosting! I don’t need to scale the app! This is a huge relief. URGENT QUESTION: Why are we trying to even do this?

            Erm, yes you do. Unless you can afford to run your computer 24/7 so someone can see the site, or you have maybe 50 other people that use dat that are willing to seed your site.

            The other problem is that Dat is simply a web-only technology. That is, unless the development of libdat has picked up recently, from being totally dead. Although, you can’t blame them because last time I looked at the source code there really isn’t a ‘libdat’ protocol. A major chunk of the protocol is built on the back of two nodejs-only libraries that handle dht swarm communication. Much of it was completely unspecified other than in those two implementations. The amount of ‘dat’ on top of that was simply a port number and a couple of async libraries.

            1. 2

              Agreed that to reliably host a Dat archive, you need to maintain a server, or use a cloud service like https://hashbase.io/.

              The Dat protocol has recently been documented in much more detail, which can be found at https://www.datprotocol.com/ - particularly the “How Dat Works” guide is excellent: https://datprotocol.github.io/how-dat-works/

              Alternate implementations, in Rust (https://datrs.yoshuawuyts.com/) and C++ (https://datcxx.github.io/), are currently in progress. These are currently not fully usable yet - in the case of the Rust implementation, the implementation is blocked on the standardization of async APIs in Rust (https://areweasyncyet.rs/). The lead developer of the Rust implementation is part of the Rust async working group, so this should all be coming along soon. Currently, it’s possible to read the Hypercore data structure, but not replicate it across the network, as far as I’m aware.

              1. 1

                As the number of users scale, theoretically the number of users seeding the site also scales, yes?

                This has certainly proven to be true for torrents, where I’ve been able to download even seemingly-obscure torrents at any hour of the day without issue.

                1. 5

                  This has certainly proven to be true for torrents, where I’ve been able to download even seemingly-obscure torrents at any hour of the day without issue.

                  I have several torrents that get only tens of kilobytes with a single peer, and I have encountered numerous others that have several leechers with no listed seeders. For an example of this, a while back ctrix handed out USBs of previously unreleased music and music that was (used to be?) on his website, at gigs he did. That USB was put on filesharing sites, I’ve seen a magnet link for it. However, the torrent is as dead as a doornail.

                  The author says that dat “truly RESISTS centralization” when it’s the opposite. It’s openly encourages such centralization because of the ‘one writer’ policy. Common sense says that if you can only make a website from one machine (i.e. moving or losing machines causes the site to become immutable), then you’ll do it from a 24/7 hashbase server or something similar.

                  Ultimately the question is: Do you want to store a copy of every single site you’ve been to?

                  Most users don’t.

                  As can be seen with Torrenting, it rests in the hands of people who can afford Terabyte hard disks, fast internet, and seed boxes. Because the ranking of what is seeded is popularity, the internet equivalent of sites like CNN and such will get extremely high bandwidth.

                  As the number of users scale, theoretically the number of users seeding the site also scales, yes?

                  Exactly! So, those who can afford servers will be more popular (Or conversely, those who are more popular will need to afford servers less) because their site is available 24/7, so they have to spend less on scaling.

                  At the risk of sounding over-critical:

                  In other words, those who aren’t able to have seedboxes and fast internet, won’t be affected or touched by Dat, and those who already can have seedboxes and fast internet, will be better off because they suddenly don’t have to pay as much for those things. This is like the thousands of other efforts by the middle class to aid the ‘poor’ and give the ‘power to the people’ – because they have no idea what poverty really looks like, because they have no experience of what being poor is like, and because they haven’t thought about the impacts of what they do past “this will be really cool and might work”.

                  1. 3

                    They were not thar obscure then ;)

                    I did try download some actually obscure torrents and sometimes it even took several months, if I ever managed to complete it.

                1. 1

                  How does resolution work? In beaker, if I type in lobste.rs it seems to resolve to https://lobste.rs but what if someone hosted a file that was equivalent to dat://lobste.rs?

                  Sorry if its a trivial question for those in the know but thats what immediately comes to mind.

                  1. 2

                    The DNS resolution works either using a DNS TXT record, or a HTTPS request to /.well-known/dat. This is specified here: https://www.datprotocol.com/deps/0005-dns/

                    An example is https://beakerbrowser.com/.well-known/dat.

                    This ensures that only the owner of the domain (or the owner the page hosted on the domain) is able to publish a Dat site using that name.

                    1. 1

                      If you visit an https:// website that also supports dat://, you’ll see [an] indicator in Beaker’s URL bar