You may have noticed in recent weeks that we’ve not been posting on Medium as much as we used to. That’s because we’ve moved our blog to our main website. We’ve been busy making product updates and publishing content and our website blog and social media pages are the best places to keep up to date with everything at Zinc.

We really appreciate our readers from the Medium community and although we’ve moved on, we wouldn’t want you to miss out on the great content we produce. In our new blog, you’ll find product updates, articles on key topics within HR and recruitment such as culture and onboarding, as well as free resources such as Zinc’s complete guide to reference checks. Eventually, we’ll be migrating our content from Medium to our website blog so you will be able to find all our content in one place.

Why not browse some of our recent blog posts and get some new ideas for your hiring journey:

• Culture add or culture fit?
• The best questions to ask when checking references
• Evolving culture: panel discussion
• Top 5 hiring tips for culture-fit

We’d love for you to keep in contact and you can do that by signing up to our newsletter or by following us on Twitter and LinkedIn.

Stay in touch 👋

We’ve moved was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why is referencing broken? The practice hasn’t evolved since the dark ages, when Fred Flintstone landed his first stonemason apprenticeship. Aside from referencing technique, a simple place to start is asking better questions. There are countless studies into interview questions. This has translated to iterations of advancements in interview questioning. But we revert to the dark ages when it comes to referencing. We ask impossible, loaded, closed questions like “Would you rehire?”, “How many sick days did they have?” or “Did they have any disciplinaries?”.

Is it any wonder we get reference refusals, useless date checks and biased information with this primitive line of questioning?

“Ask the right questions if you’re going to find the right answers.” — Vanessa Redgrave

Zinc have been studying referencing for some time. Our platform offers an automated ‘culture-add referencing’ tool.

We’re open sourcing a culture-add reference question generator – Janice. The aim is to encourage better questioning in referencing and inspire new ideas for information to extract. In order to try and better referencing for all.

Click below to speak to Janice and generate reference questions for your company…

👋 >> Click Here <<👋

Zinc’s redefining the reference check, learn more about how their automated tools and how can help you hire: https://zinc.work/landing/referencing.

Website: https://zinc.work

Twitter: https://twitter.com/zinc_work

LinkedIn: https://www.linkedin.com/company/zinc-work/

Reference Question Generator was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can run a good recruitment team with tactics. You can run a great recruitment team with strategy. In early 2019 the zeitgeist is pointing us firmly in the direction of doing more with less, and RecOps can help us to do just this. By taking a step back from the daily grind of ‘Find, Recruit, Hire, Repeat’, ‘Find, Recruit, Hire, Repeat’. RecOps can be used to spot bottlenecks and inefficiencies and in time, make everyone’s lives run more smoothly.

With RecOps meaning different things to different organisations, it can be hard to put boundaries around a role with such potential and breadth. For the role to be effective and have impact, this is exactly what we must do.

Hang on, RecOps? Also referred to by it’s more popular sister term TalentOps but not to be confused by its brother term PeopleOps — what is it?

Greenhouse defines ‘Recruitment Operations’ as a set of recruiting activities and processes that help a talent acquisition organisation run effectively, efficiently and in support of hiring strategies and objectives. In short, RecOps reduces friction in the recruiting process.

This helps, but it is still pretty broad, it’s probably in the spec for almost every talent leaders role. My advice to anyone working in this function is to be extremely clear on what is expected from the role in the context of YOUR organisation. Naturally RecOps tends to become an independent role in organisations that have mature people functions. One of the key differences in the teams I have seen — in these mature setups is that RecOps doesn’t carry headcount. The RecOps role no longer is responsible for hiring, it’s becoming a specialist field. Whilst talent leadership does often ask for Recruitment Operations skills, Recruitment Operations doesn’t necessarily require Talent Leadership skills. It demands a different skillset and that is often affirmed by the broader set of backgrounds that feed into Recruitment Operations roles (PM, Dev, Office Manager, Support, Marketer & strangely — Recruiter). The paradigm varies from office administration in incumbents to highly technical work configuring systems and manipulating data sets in modern people functions. This is our assessment…

TL:DR Recruitment Operations is becoming a specialist field in some organisations we believe it’s demanding more technical skills. Technical administration skills and data management. Meaning interview and attraction skills are no longer imperative.

Strangely, the portmanteau addition to recruiting titles rose to popularity around a similar time that the DevOps, SysOps, SecOps titles emerged out of System Administrators. A term born out of agile leaders blue sky session to squash everything into one role. Again, wanting to be strategic and operational so they too needed a fitting title.

If your getting into Recruitment operations or your already in it and want to make your RecOps more of a specialist domain then here’s some brainfood to chew over in 2019.

1. Data, Data, Data

In a role that sits outside but alongside the ‘hiring’ process, RecOps Managers often have an entirely different skillset and background to the rest of their team. At the heart of this skillset is the ability to effectively process and analyse data.

It would be hypocritical to suggest that data was important without showing some data wouldn’t it? According to the Bersin 2018 report, high performing TA functions are 6x more likely to use database driven decision making and high performing TA functions are 3.2x more likely to supply top talent. Which is probably the single most important goal for every TA function.

Okay, it’s important, what can you do with data? If you’re lucky enough to have a good HR/TA systems then you’ll likely have a treasure trove of data…

1. If you haven’t crunched 2018’s numbers then set some time aside to do it soon. You can’t move forward and improve without an understanding of where you are now.
2. Utilise predictive analytics for forecasting at least support budgeting and headcount and build your 2019 TA strategy.
3. Does your recruiting data tie in with onwards talent management, performance data and learning data and internal mobility data?
4. Is your Recruiting data’s success metrics integrated with the businesses success metrics? Career development, culture, strategy.

Some fairly simple data analytics can quickly shine a spotlight on some of your biggest bottlenecks.

Forget ABC and learn how to ABT (always be testing) in 2019. Run experiments and test. It’s a fundamental product development technique that is easy to incorporate into any campaign. If these skills aren’t in your team, ask your ATS/HRIS/HCM partner for some tips on their reporting tools.

2. Critical thinking to apply Automation and AI

Again, according to the Bersin 2018 report, high performing TA functions are 4x more to embed technology in their processes such as Automation & AI cognitive tools.

What can you outsource to the robots? Automation is nearly always a good thing. Your ATS likely has a plethora of integrations available to automate parts of your process. Audit every single hour of your hiring/on-boarding process, every hour of your team’s time and every hour of your applicants. What can you pass off to technology that will reduce your bias or save your team time?

By using automation tools wisely, you will start to free up time that can be invested elsewhere in the function. However, bear in mind that whilst automation can sometimes be useful in the short-term, it can increase workload further down the funnel. Harness critical thinking to evaluate bottlenecks and apply your tools — from end-to-end. It could be the length of time it takes to schedule on-site interviews or collect references. Whatever, it is, you need data & critical thinking to prove & improve it.

3. Law requires you focus on inbound (GDPR).

Heard this one before? It doesn’t feel entirely original to be saying this year we’ll be focusing on inbound. But it’s for different reasons this time, reasons that can has catastrophic impact on your business. We recently saw the first GDPR fine slapped on Google. If those shots fired weren’t enough to make you sit up and question how compliant your job board & ATS suppliers are then I’m not sure what is. If Google can’t get it right then who else can? Define a data processor for your TA/People function, this might well fall down to you in RecOps.

Job boards are a huge outbound cost and with GDPR in mind, perhaps 2019 is a good time to use the RecOps function to look into new funnels for engagement. It’s well known that mature recruitment functions focus on strategic sourcing. Strategy in the field of recruiting sounds familiar ~that’s RecOps. What strategic tools or channels can help to source & interview for work ethic, values and potential? Rather than purely focusing on past skills.

4. A product-driven approach ~ Create Personas, personalise journeys

RecOps isn’t just about data crunching, it is about marrying the strategy and objectives of your business to the recruitment function. With the challenges of our everyday jobs and targets, it can be easy to lose sight of the bigger picture and to think of ourselves and our candidates as people. Make sure your team invests the time to think strategically and spend time re-evaluating and re-defining your recruitment voice and what you stand for. Think about what type of person your ideal candidate would like to engage with to create and re-evaluate your ideal candidate and recruiter personas. What language and tone of voice do they use? You may have 4/5 target candidate personas, what can you do to personalise the journey for each of these funnels?

Spend time role-playing in your team and building a consistent voice. In a competitive marketplace, this will help you stand out and should also bring more fulfilment and satisfaction to the team.

5. Communication channels of 2019 ~ WhatsApp & Chatbots

2018 was the year that workplace communication tools exploded with Slack everywhere and Facebook launching is workplace tool.

WhatsApp is a global phenomenon, with read and response rates eclipsing email and SMS. WhatsApp now offers business accounts and an open API. You can build automated campaigns and add team members to corp accounts.

Chatbots were tipped to be big in 2018 but didn’t quite take hold. They may reach their tipping point in 2019 with impressive stats on engagement of applicants. Both are way to boost engagement in 2019 that recruitment operations managers should know about.

In summary, RecOps is undoubtedly a strategic business function that has become increasingly necessary in large talent organisations today. It has huge potential to bring efficiencies and streamline processes.

Zinc offers automated employee background checking tools. Zinc’s redefining the reference check, learn more about how their automated tools and how can help you: https://zinc.work/landing/referencing.

This post was written in collaboration with Recruiting Brainfood (www.recruitingbrainfood.com).

Get in touch if you’d like support using the Zinc’s blockchain based hiring toolkit to build a distributed team; hello@zinc.work.

Website: https://zinc.work

Twitter: https://twitter.com/zinc_work

LinkedIn: https://www.linkedin.com/company/zinc-work/

The Rise of RecOps was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Perfecting your interview process for building distributed teams

Building distributed teams part 2

Zinc’s on a mission to “Open source interviewing”, by providing tools to allow applicants to retain and reuse data collected whilst interviewing. In this blog I’ll be analysing interview processes of leading teams in web3. So this is the perfect place to launch a ‘Open Source Your Interview Process’ movement. We’ve started off a list of teams that have ‘open sourced’ their interview processes, listing publicly on this Github repo. If we’re able to share notes, we can learn from each other and all spend less time interviewing. If your company is willing to share your interview process and contribute then please add it here.

The negative press crypto brings to blockchain is counterbalanced by the radical openness and transparency some teams adopt. In some cases this transparency and openness carries through to careers pages. Some interview processes are listed publicly on jobs pages, others that I’ve reached out to are happy for their processes to be public. That’s why it’s no surprise that web3 teams are leading the charge in the remote revolution. We found that twice as many web3 teams were distributed compared to the rest of tech. It’s this kind of radical openness which is allowing web3 leaders to attract and retain top talent across tech and beyond.

Distributed teams are being hailed as the new route to efficiency and productivity, with minimal time lost to commuting, unnecessary meetings, gossip or other distractions that come with having an office-based team. Everybody’s free to work where and how they want, taking full ownership for their own productivity and output, without becoming embroiled in wider company issues, if they don’t need to be (who does :)

We now know why remote teams are worthwhile, but what do you need to put this in in place?

Leading Web3 Teams Processes

Aragon’s process

Success stats: Truly globally remote, no offices. 21 people work across Aragon’s teams, 20/30 outside contributors at once. Aragon’s privacy preserving interview techniques, like IM interviews are commendable: https://wiki.aragon.org/jobs/

Blockstack’s process

Success stats: Globally remote, distributed across Hong Kong, Gambia, Barcelona, Toronto, and Seattle. 24 core team members + open source contributors. Flexible process & powerful values (voted for by the team): https://blockstack.org/careers

Blockchain.com’s process

Success stats: Distributed across UK, SF & New York. Scaled to over 150 in the past year. Bonus points for the nicest interview graphic. Unlimited PTO, flexible schedules and crypto bonuses: https://www.blockchain.com/careers

Bitpesa’s process

Success stats: Globally remote, offices in Lagos, London, Luxembourg, Madrid, and Dakar. Over 60 people globally, challenging hiring in emerging markets: https://www.bitpesa.co/careers/

Bitfinex’s process

Success stats: Truly globally remote, distributed across Asia, Europe & Americas. Culture of Learning offsite’s and team building, flexible hours: https://www.bitfinex.com/careers

Status’s process

Success stats: Truly globally remote, no offices. Scaled to 100+ people in the last year. Will pay in SNT or local fiat. Extremely flexible, no set interview process & serious about privacy: https://status.im/contribute/applicant_privacy.html

Zeppelin’s process

Success stats: Truly globally remote, offices in Buenos Aires. On average the process takes 4–6 weeks. Good wiki. Work tests are paid should and are roughly 10 hours weekly, spanning no more than three weeks. Smart to be referencing early on: https://zeppelin.solutions/jobs/

Disclaimer: these processes are taken from job specs, online forums & here-say: I’m certain they’ll vary between jobs and will likely be outdated soon.

From this small sample of distributed teams we can see there is an average of 5.7 stages in their interview processes. For centralised tech teams this isn’t too dissimilar. Which helps dispels the myth that you need more rigorous processes for remote teams.

As you’ll see from the highly confusing diagram below, whilst all the processes are comprised of the same components the flow varies greatly. In fact, no two processes are the same. We encourage teams to share notes and learn from each-other so we can all spend less time interviewing. Below I’m going to pick our of favourite parts to encourage teams to experiment and iterate on their processes.

Perfecting your process to build distributed teams

At Zinc, we’re working towards reducing assessment load, time candidates and recruiters spend interviewing. We’re strong believers in respecting people’s time.

We’re identifying the most effective task at each interview stage to find out if it’s worth asking your applicant for more time. At each stage collect the critical amount of information needed to know if it’s worthwhile moving to the next stage. No unnecessary jumping through hoops.

Considerations for each interview stage:

• First stage phone screen: Some in the modern workforce lack the sophisticated communication skills to be effective remote workers. Often the greatest challenge with creating effective remote teams is communication. That’s written, video and face to face communication. These forms of communication require different skills ~ since we have different tools at our disposal to get our message across; body language, verbal tone, emoji’s and most importantly GIF’s. The remote team reality is that calls a crucial form of communication. From this crucial first stage you need to be confident that this person is a very competent communicator over the phone.
• Instant Messenger interviews: This is one I was pleased to see deep in Aragon’s docs, they often support instant messenger interviews. I can see the sceptics turning their nose up at this idea. The pessimist out there will tell you a story about when they’ve caught candidates Googling answers, we’ve all been there. But the pessimists are missing the point. This is a great communication test. We all Google answers everyday at work so why not replicate this. IM is your day-to-day communication tool. I can tell you for free that being able to write good Javascript does not translate to being able to write good English. In fact the pessimist might say there’s an inverse relationship here.
• Technical Tests: This stage is included by all the leaders in some form other than Status. It varies in its form greatly. Tests with Bitfinex prior the face to face ask for 4–8 hours of applicants time. A ‘work test’ at Zeppelin asks for up to 10 hours over up to 3 weeks, paid. Better categorised as a trial. The technical test is the most contentious part of the process. It’s the largest time and effort commitment ask of applicants. We assume that’s why Status have left it out, having the luxury of a flourishing open source community of contributions. We recommend you take a leaf from Status’s interview hand-book and swap unpaid tests for paid work trials where possible. This is a better way of replicating the work that engineers will be doing. Where tests are necessary we suggest that work is open sourced. Consider the time and effort asked of applicants very seriously first. Zinc offers an interview proofing tool to gift job applicants to verifiable claims of work completed in interview processes ~ such as tests. This allows applicants to have something permanent and provable to take away from interview processes so time isn’t wasted.
• Work Trials: it’s a small sample size but all bar one of the above organisations include a trial in their process. Hiring remote teams is arguably harder since we have to judge whether an applicant will excel in a remote environment. For other facets of the work, we’ll look at an applicant’s past performance to see if they have excelled. Since remote teams are a relatively new phenomenon we often don’t have past experiences to take from. This is of course a vital factor in anyone’s success in a job. Again it’s advisable to try and recreate the conditions of the job as closely as possible in the interview process. Hence a remote working trial is an effective way to recreate the job. You could say this about any job of course. The downsides to it are the time and cost. It can take your interview process from something that takes weeks into months.
• Background checking: Some employers are surprised to hear that distributed employees still need proof of right to work & residency for the jurisdiction they are working in. You need to ensure that the person your employing is eligible to work where they’re located. This comes down to tax because all employers need to cough up in the home country of their employee, which is only possible if they’re a resident there. Local rules apply but it’s highly recommended to check proof of residency & right to work ID docs for everybody. Again you can check employment references & educational history with applicant’s consent. For any other level of check; criminal or financial, check the local rules since they vary wildly. For instance, in the UK you can conduct financial or criminal checks for workers in certain industries; healthcare, government or financial etc. The extra anonymity and trust that comes with remote working makes it all the more contentious but all the more important. Do the necessary; residency, nationality and employment checks but respect privacy, don’t do more that is necessary or legally allowed. Part 3 of this series will focus on this minefield.
• Referencing: You’ll notice that a couple of companies explicitly mention that they conduct references. We believe references are an essential part of a remote teams process regardless if you’re looking for competency information or not. It’s one of the few background checks that’s universally allowed. Trust is such a significant part of remote working. It’s one of the most dramatic differences from on-site work so it’s essential you know that the trust is there from the outset. What’s interesting to take from the example processes above is when the referencing takes place. Zeppelin conduct references two stages before an offer. Blockchain.com conduct references at the end of the process ~ which is more common from my experience. I believe this is because of the frustration in the time it takes and the difficulty in obtaining valid responses. Equally, the lack of competency information being extracted has pushed it back in the process. However we suggest taking a leaf out of the Zeppelin’s interview handbook. Aim for competency information early on, and start referencing prior to the final stage. This will enable you to have so you have the necessary information to make a decision after the trial or final interview.

Full disclosure: I’m advocate of referencing, we offer an automated referencing tool at Zinc. I have my own conscious bias on this subject.

• On-boarding: Aside from the stats above empathetic on-boarding is more important than ever. To the wider working world, remote teams are still a new phenomenon — most people have not experienced this environment before. With a physical barrier between new employees it’s harder to give the support they need. Someone to contact for silly questions and starting to feel like part of a team is essential.

As mentioned above the last piece in the distributed teams series will be focusing on the minefield of navigating background checking globally distributed teams. Read on.

This post was written in collaboration with Recruiting Brainfood (www.recruitingbrainfood.com).

Get in touch if you’d like support using the Zinc’s employee background checking tools.

Website: https://zincwork.com

LinkedIn: https://www.linkedin.com/company/zinc-work/

Perfecting your interview process for building remote teams was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are so excited to be listed on Product Hunt today — the place to find the best new products in tech.

Each day Product Hunt user data (upvotes, comments) is used for ranking new products — the higher the rank, the better the exposure.

About Zinc

Zinc is democratizing the hiring process, with automated referencing, feedback and background checking tools that put the candidate in control of their data. For employers, a built-in incentive system makes sourcing references simple and straightforward, including gathering in-depth insights on candidate skills and work styles.

For job seekers, Zinc turns the data ownership model on its head, empowering candidates to own data they previously missed out on. Data such as references and other work proofs; interview feedback, courses, and hackathons. This data can be reused throughout the job seekers career to avoid repeating these processes over and over.

Check out Zinc on Product Hunt and show your support 🚀

Swag & Discounts

• Hunters who are recruiting can enjoy 50% off for 3 months: Redeem by emailing hello@zinc.work.
• Hunters who are jobseekers can earn $5 or a Zinc t-shirt for building their profile! Redeem here.

Product Hunt: www.producthunt.com/zinc

Zinc is LIVE on Product Hunt was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The days of water-cooler moments, office politics and 9 to 5 work days are officially numbered. Co-working has gone mainstream, remote working is ‘the new normal’ and DAO’s are seriously on the horizon. Now a significant number of businesses are proactively choosing distributed global teams over a central office location.

As usual, tech businesses are leading the way, with brands such as Basecamp and Github getting on board early. Most of all blockchain & Distributed Ledger Technology (DLT), Zeppelin, Consensys, Status and Bitpesa have built it into their DNA from day one. That makes sense, the technology is founded on the principle of decentralisation and Bitcoin and Ethereum are distributed team success stories. Other than these innovators, how many tech companies are distributed?

Blockchain jobs are twice as likely to be remote

We analysed data across three major job boards and found that there’s roughly twice as many remote developer roles in companies that had blockchain or DLT in their job specs.

• 1% of developer jobs with blockchain on Indeed are remote >>>>>> 0.3% of other developer jobs on Indeed are remote.
• 29% of developer jobs with blockchain on Angelist are remote >>>> 15.7% of other developer jobs on Angelist are remote.
• 12.1% of developer jobs with blockchain on StackOverflow are remote > 6% of other developer jobs on StackOverflow are remote.

Data collected: 22/11/18

This data isn’t surprising since the values of blockchain technology companies often align with the sentiment of remote working. Democratisation of power, privacy and decentralisation.

The drivers and the deterrents to distribute

There are a number of drivers behind the move to distributed teams, not least the battle for the best people. Tech talent is hard to find and extremely expensive, which means young start-ups have been priced out of the traditional hotspots, like Silicon Valley, London and Berlin.

Many have responded by scrapping the idea of having a permanent base altogether, instead embracing the opportunity to pluck tech talent from every corner of the hyper-connected world, and the chance to get shot of staid office structures at the same time.

It sounds like workplace utopia, however shifting to a fully distributed model isn’t without its challenges. In fact there’s a plethora of problems that come with these perks. There’s naturally an impact on company culture, team trust and collaboration, which means getting the recruitment and peopleOps processes right is vital.

Building a distributed team: Making it work for everyone

• Invest in workstations: Every employee needs to have fast internet and easy access to video conferencing software to give them the opportunity to excel in your organisation. Distributed employees may well have access to great personal technology but provision of top end equipment needs to be default for any company practising the distributed model. Of course you have no control over the environment that equipment sits in — that’s part of the empowering perk for each individual.
• Reduce geographical bias: We talk a lot about tackling unconscious bias at Zinc and the detrimental effect it can have on hiring; access to talent and diversity. Geographical bias is almost unavoidable for centralised teams. We will often look at CV’s and discount those who don’t live locally, naturally favouring those who have an easy commute or don’t have to relocate. Building a distributed team immediately removes this bias.
• Distribution for built-in diversity: Without geographical bias we can build in diversity by design. You can hire by meritocracy — the best skills and fit from your global talent pool win the job. Restricted communication channels do have some benefit — they block bias to different shapes, sizes, skin tones and supposed abnormalities in individuals.
• Feeding back and spending time ‘together’: One of the big dangers of distributed teams is that people will feel disconnected from their colleagues. A method to avoid this is through a structured routine of phone or video-based ‘get-togethers’, on a daily or weekly basis. How you choose to run these is up to you but ensure that everybody feeds in about what they’ve achieved since you last caught up and what your focus is for that day or week. Make sure these happen come rain or shine, giving your team time to connect, hear each other’s voices and stay in the loop of what everybody else is doing.
• Physical contact not ‘FaceTime’: And yes, it also helps enormously to actually meet up from time to time, to strengthen those team bonds. Nothing beats spending physical time together to build trust and relationships so, even if it’s just once every six or 12 months, it’s worth the challenge of coordinating diaries and spending a bit of cash to make it happen.

This is part 1 of our distributed teams series. Maybe I’ve wet your appetite to find out how to build a distributed team, maybe you feel like a duck out of water. If the former, stay tuned for part 2 to read about creating an effective interview process for building distributed teams.

This post was written in collaboration with Recruiting Brainfood (www.recruitingbrainfood.com).

Get in touch if you’d like support using the Zinc’s background checking toolkit to build a distributed team; hello@zincwork.com.

Website: https://zincwork.com

Why twice as many Blockchain teams are distributed was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

First, I’ll explain our ID checking philosophy and how it can provide value to your hiring process. Or skip straight to the instructions by clicking here.

Recently I was fortunate enough to travel in Africa. Over the week, I had more than 10 copies of my passport taken by the various hotels and the border authorities. For anyone whose privacy conscious, this is hard to accept. Copies of my passport sitting on invariably insecure networks and IT systems - likely, forever. That’s a concentrated version of the exposure your ID docs have over the course of your career…

Problem 1: A tech professional who works as permanent member of staff, may face their passport being copied 10x over the course of their career. These are probably more trustworthy systems you have a higher level of tolerance for. However if you work in the gig economy as a contractor or freelancer, this might be 5 or even 10x higher. Likely by less well known intermediaries, agencies, consultancies and everyone else in between who has a checkbox to tick.

Problem 2: Employers are looking for ‘proof of right to work’. For this, most roles just require your name + nationality and know your identity document is valid. Employers don’t in fact need the passport number, date or place of birth. Yet this information is copied regardless and again, these copies will usually sit on the IT systems of the intermediary for as long as they exist.

Applicants prove their right to work over and over throughout their careers, exposing their identities to the same check repeatedly. Secondly, we overshare all our ID doc data, more than is necessary or even useful to have. These are the two problems we’re solving with blockchain anchored national ID proofs. Here’s a recruiters guide to using our proof of right to work tool.

1. Find the right candidate (the difficult bit).
2. Sign-up or sign-in: https://zincwork.com/ with LinkedIn, email/password or MetaMask. Use a company email for validation where possible.

3. Request ID Check: navigate to the recruit tab on the left menu bar. Click the ‘request ID’ button on the top right of your page. Complete the form, entering the candidates name, email, the number of references you’d like back. Clicking submit will cost you 10 credits per ID check.

No further work is required. You’ll be notified of the results by email. You’ll be delivered back: “Name, Nationality & ID Validity”. This removes any GDPR risk. Behind the UI we pass the image file to an API to read only the relevant fields of the ID doc. Our API can scan and identify any nationality passport globally using two techniques:

1. MRZ verification performs analysis checks on the Machine Readable Zone (MRZ) values specified by the user.
2. Image verification performs image, Optical Character Recognition (OCR), and MRZ analysis on the attachments associated with the supplied document.

Your request triggers an email to go out to your candidate. They will go through this process…

1. The applicant gets an email asking them to complete the proof of right to work ~ ID check. They’ll be informed that unlike other ID check providers, they get to keep this immutable ID proof afterwards. It may save them going through this process again and again throughout their career.

2. Click the email link taking them to zinc.work to upload their ID securely on a webpage. Their ID is checked privately by an API, taking on average 3 seconds.

The results are delivered back to the applicant and the recruiter within a few seconds. The passport or identity document details always remain completely private and are only read by the API. The proof of ID check results of are recorded on the Ethereum blockchain. The applicant can then use their Zinc identity to prove their proof of right to work in the future. The applicant can share this proof in a zero knowledge fashion by only revealing proof of the data they wish to.

Please get in touch if you have any questions or need support: hello@zinc.work

Website: https://zincwork.com

ID Checking Your Candidates was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zinc is a Web3 based hiring toolkit that includes an automated referencing tool. I’m going to walk you through the process of signing up to collect your first candidate reference. I’ll also show you the journey your candidate and their referee will go through so you can get an overview of the whole journey.

1. Sign-up to https://zincwork.com/: you can signup via; email and password, LinkedIn or MetaMask. LinkedIn is recommended to attach any existing current professional reputation to Zinc. If you choose another sign-up method, you can connect your LinkedIn from your account page once signed up anyway.
2. Request reference: navigate to the recruit tab on the left menu bar. Click the ‘request reference’ button on the top right of your page. Complete the form, entering the candidates name, email, the number of references you’d like back and a note to them. Hitting submit will cost you 10 ZINC tokens per reference.

Receive your reference: Nothing else is required. You’ll be notified by email when the references are ready and you’ll view them in a unique shareable link. Don’t worry we’ll pass the necessary messages onto the candidate and referee and we’ll do the chasing. We incentivise the referee to respond quickly and authenticate with LinkedIn. We’ll notify you if there is a date mismatch too.

This video demonstrates the full reference process from the recruiter, the referee and workers persona.

Get in touch if you’d like support; hello@zincwork.com Or we’d love to hear your feedback too.

Website: https://zincwork.com

A recruiters guide to referencing a candidate with Zinc was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

IPFS — Interplanetary File System is awesome for storing data in a decentralised fashion and it’s one of the most commonly used tools for storing data within the blockchain space. Storing data within a Blockchain is expensive and slow, storing in IPFS is free and fast. IPFS does not allow duplication of data by hashing it and hashing the same data twice will give back the same hash.

IPFS seems to work really well. You can add data and it stays in this global network of nodes. Anyone with a hash can access the data (note that all data on IPFS is public unless you use a private IPFS node) and the same data is not duplicated. The question that you might be asking at this point is, “Can I change my database with IPFS and become fully decentralised?”

While IPFS is great at storing your data, it does not give any guarantees of the data being available if your IPFS node goes down. Confused? Imagine this. You start your IPFS node, run it for a month and have very important data within it. Your machine breaks, you’re thankful it's a public network so other people will have your data, right? Not quite, IPFS never guaranteed your data will always be available. No other node was interested in it and therefore no one else pinned your data except your loyal node. Consequently your data is lost since no other node has it.

This is where Filecoin comes in, Filecoin allows other nodes to be incentivized for storing your data in case your node goes down and a small fee on your end to avoid losing your private data. Filecoin is awesome, let's use it! Well, it's not there yet… Filecoin is under development and will be available at some point in the future. For now, we have to work with current solutions, which include:

1. Running multiple IPFS nodes
2. Backing up ~/.ipfs folder
3. Running IPFS-cluster
4. Using something else (ie Storj)

There are more solutions than this but the one I want to talk about is the Ipfs-cluster. The Ipfs-cluster lets you run many nodes which each replicates the data and keeps the nodes synchronised by using RAFT consensus. Lets look at how many nodes we need to keep the system secure. A general case is that a node may go down or lose internet connection. Assuming we have t nodes, we need at least t+1 to keep the system running, in simple terms; it just means there should be at least 1 node up and running even if all others are down. So if you think 5 nodes can never be down at once then your risk factor t is 4.

IPFS cluster uses IPFS nodes to store data and its built on top of standard IPFS which means using the cluster does not mean running a different IPFS node but the exact same node you will run if you were using plain IPFS. IPFS cluster has a proxy node which is used to store all pin requests and implements RAFT algorithm (Leader based approach).

The idea is that you would interact with the IPFS cluster proxy node which handles synchronisation and backups so you can treat it exactly as an IPFS node. IPFS-Cluster nodes exchange messages between each other such as a request to pin a hash or sending out heartbeat messages to know if a node is down. One of the biggest advantages of this approach is that once a node comes back up, it can receive all the messages it has missed and be up to date in no time.

Thats awesome! Lets use IPFS for everything? Not so fast!

Well, while IPFS is awesome in many ways (there is even a repo) it has its problems too. IPFS node can get quite hungry in terms of memory usage as it connects to more and more nodes continuously - not to mention the amount of bandwidth it consumes! 1 GB of memory is not enough for IPFS nodes and what happens is that the Operating System (Ubuntu) kills the IPFS daemon once it starts using too much memory and all you will see when you look at it is a word “Killed” . It is as devastating as it sounds and if your application depends on IPFS being up full time then you would need a machine with more memory and bandwidth capacity. However; there are other solutions on solving this problem. (Note that this is a problem with IPFS node and not IPFS-cluster).

Limiting the number of nodes that IPFS connects to can resolve this problem and this can be done in one of two ways (everything discussed here is in the config file for ipfs found at ~/.ipfs/config).

1. Manually: By changing the config file to disable MDNS Discovery or setting the interval too high (not recommended, it essentially isolates your node from rest of the network and there is a probability that other IPFS nodes will be able to get content from your node but its very low).
2. By using the IPFS connection manager to limit the number of connections your node makes. This has three attributes:
    — Max Connections:
   Maximum number of connections that your node will allow and start dropping connections after that.
    — Min Connections:
   Minimum number of connections that your node will try to maintain
    — Interval:
   The amount of time after which max and min constraints will be checked, for example, if its a minute then every minute your node will ensure that Min ≤ number of peers (ipfs swarm peers | wc -l ) ≤ Max Connections

Most of the problems with IPFS can be solved with updating the config file or reading the docs, if you have any questions or suggestions, please comment below or message me on twitter @aliazam2251

Website: https://zinc.work

Twitter: https://twitter.com/zinc_work

Telegram: https://t.me/zinc_work

Reddit: https://www.reddit.com/r/zinc_work/

Entering the world of IPFS was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Looking for code? SKIP to “Example Code”. Cryptography is a powerful tool for protecting the ownership and control of data —a necessity for any self-sovereign identity solution. This page gives a short introduction to a list of design principles and considerations of a scheme designed to decentralise the control of user data on a network.

Cryptography In Practice

Protecting data requires the careful planning of software, hardware and network infrastructure in combination with cryptographic algorithms which obscure data with secret keys. As far as implementation goes there’s a fair warning: use existing and well used protocol where possible and don’t invent your own cryptography.

Symmetric vs public-key cryptography

Symmetric-key algorithms use the same key for both the encryption and decryption of a message. This key, in practice, represents a shared secret or a password with which two parties can transmit messages securely. The requirement that both parties have access to the secret key is one of the main drawbacks of symmetric key encryption since it requires that the secret key be shared in person or using existing secure lines.

Public-key (asymmetric) cryptography uses pairs of keys: public keys which may be shared widely, and private keys which are known only to the owner to accomplish encryption whereby two parties can communicate securely without prior knowledge of a shared secret. A message can be encrypted using a public key in such a way that only the matching private key can be used to decrypt that message. This way a message can be transmitted to an intended recipient securely by simply encrypting it using their public key.

Key management

The generation, distribution, storage, use and destruction of cryptographic keys is a highly sensitive component of any data protection scheme and the topic deserves a much longer article. The main challenge for a self-sovereign identity solution is to distribute keys in such a way that only the true owners of personal data can access or control it. The most obvious solution is to have each owner themselves generate and store a key pair and carry out the encryption of their data on a local machine — without needing to ever share or communicate their private key. Distributing encryption and key generation amongst a network of users enables the control of data to be truly decentralised. But this solution isn’t trivial and requires an application or browser extension to manage the local storage of keys and the encrypt/decrypt function.

Tweetnacl-js

Tweetnacl-js is a popular js library for encrypting data asymmetrically using the TweetNaCl protocol (TweetNaCl is a lightweight fork of NaCl). TweetNaCl is designed by the highly regarded cryptographer Daniel J. Bernstein.

Why TweetNaCl-js:

• Library meets the minimum requirements for most use-cases: asymmetric cryptography, high-level library, authenticated encryption, incorporates initialisation, lightweight
• Has been audited by security firm Cure53
• Popular in the crypto community e.g. MetaMask, Stellar, Peerio, Keybase, uPort
• Well used and many downloads on npm

Diffie-Hellman protocol:

TweetNaCL implements the Diffie-Hellman protocol to achieve asymmetric encryption:

Alice’s public key is combined with Bob’s private key to derive a shared key. This key can also be derived by combining Alice’s private key with Bob’s public key — hence it’s a shared key. Alice and Bob can now communicate securely using this shared key to encrypt and decrypt messages using a symmetric cryptographic algorithm.

Ephemeral (temporary) keys:

Using the Diffie-Hellman protocol to derive a shared key ensures that both Alice and Bob can decrypt any of their previous communications at any point in future. This effect is certainly not always desired. For example, a self-sovereign identity platform might need to encrypt personal data in such a way that only the subject could ever decrypt it — regardless of whoever is performing the encryption. In this case the sender (i.e. whoever is carrying out the encryption) can agree to destroy their key pair immediately after the encryption process to ensure that only the intended recipient (i.e. the subject) can ever derive the ‘shared’ key required to decrypt the message.

Initialisation Vector And Nonce:

Using the same key to encrypt data repeatedly can reveal relationships between segments of encrypted messages — particularly if the content of these messages is in anyway predictable. To combat this a separate value (also known as an initialisation vector (IV) or in some cases a nonce) can be incorporated into the encryption process to introduce a degree of randomness in the output. The initialisation vector is unique to each message and is required for decryption but it is not a secret key and can be transmitted in plain view. Tweet-NaCl incorporates initialisation by default and so the developer is free to make use of the ‘nonce’ property as they wish e.g. a counter value which increments with each message can be used to prevent messages being repeated or delayed spuriously (see replay attacks).

Self-sovereign identity implementation — ZINC

Key generation & storage:

Each user generates a key pair to be used in encryption. Key pairs are stored as a keystore file in which the private key is protected with a password.

Encryption:

Personal data (work identity claims) is encrypted using a key which is derived from the subject’s public key and an ephemeral private key. Only the subject’s private key can be used to decrypt the data in future.

Key extraction & decryption:

The subject’s key pair is extracted from their keystore file. Subject’s data can then be decrypted using the subject’s private key.

Sharing & re-encryption

Subject’s data is decrypted using the subject’s private key. It can then be re-encrypted using the intended recipient’s public key.

Example code:

This is some example code using TweetNaCl-js. This is not audited code and should be treated with caution.

import nacl = require("tweetnacl") // cryptographic functions
import util = require("tweetnacl-util") // encoding & decoding 

/* 
** You'll need to generate a key pair for your users e.g.
** const keypair = nacl.box.keyPair()
** const receiverPublicKey = util.encodeBase64(keypair.publicKey)
** const receiverSecretKey = util.encodeBase64(keypair.secretKey)
**
*/

/* encrypted message interface */

interface IEncryptedMsg {  
  ciphertext: string  
  ephemPubKey: string  
  nonce: string  
  version: string
}

/* This function encrypts a message using a base64 encoded
** publicKey such that only the corresponding secretKey will
** be able to decrypt
*/

function encrypt(receiverPublicKey: string, msgParams: string) {

  const ephemeralKeyPair = nacl.box.keyPair()  
  const pubKeyUInt8Array = util.decodeBase64(receiverPublicKey)  
  const msgParamsUInt8Array = util.decodeUTF8(msgParams)  
  const nonce = nacl.randomBytes(nacl.box.nonceLength)

  const encryptedMessage = nacl.box(
     msgParamsUInt8Array,
     nonce,        
     pubKeyUInt8Array,
     ephemeralKeyPair.secretKey
  )  

  return {    
    ciphertext: util.encodeBase64(encryptedMessage),    
    ephemPubKey: util.encodeBase64(ephemeralKeyPair.publicKey),
    nonce: util.encodeBase64(nonce),     
    version: "x25519-xsalsa20-poly1305"  
  }
  
}

/* Decrypt a message with a base64 encoded secretKey (privateKey) */

function decrypt(receiverSecretKey: string, encryptedData: IEncryptedMsg) {  

  const receiverSecretKeyUint8Array = util.decodeBase64(
      receiverSecretKey
  )      
  const nonce = util.decodeBase64(encryptedData.nonce)      
  const ciphertext = util.decodeBase64(encryptedData.ciphertext)      
  const ephemPubKey = util.decodeBase64(encryptedData.ephemPubKey)      

  const decryptedMessage = nacl.box.open(
      ciphertext, 
      nonce,          
      ephemPubKey, 
      receiverSecretKeyUint8Array
  )

  return util.encodeUTF8(decryptedMessage)        
}

Known Pitfalls to Beware:

1. Padding: TweetNaCl does not incorporate padding by default. This means that the length of the encrypted output will be directly proportional to the length of the input. A bad actor might learn the contents of an encrypted message simply be comparing it’s length to some known inputs (e.g.“yes” will produce a longer encrypted output than “no”). To overcome this a string of random length could be appended to each message before encryption to introduce a degree of randomisation in the length of the output.
2. Storing and using keys: By default cryptographic keys should not be stored as plain text and should themselves be encrypted and secured at rest. Another general rule of thumb is to use keys as least times as possible.
3. Nonce: Using an incremental nonce to prevent replay attacks comes with the side effect that it also reveals valuable traffic information to snoopers.

Alternatives JS libraries

Libsodium (a NaCl fork)

References

• TweetNaCl.js - JavaScript crypto library
• TweetNaCl: Introduction

This is a working document and I invite your help!

Using cryptography (TweetNaCl-js) to protect user data was originally published in Zinc blog on Medium, where people are continuing the conversation by highlighting and responding to this story.