Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dominic Wörner
    @domwoe
    The first time it worked and I got the QR code but got a 500 in the backend when I tried to issue the credential. Now, it's already failing at the log in
    Mina Nagy Zaki
    @mnzaki
    Hello @domwoe!
    Did you remember to change the serviceUrl config option in generic-backend/src/config.ts?
    Ellie Stephens
    @EllieStephens

    In case you missed it, our engineers released one of the biggest updates to date of the Jolocom library and SmartWallet. Take a look at the release notes on github here >> https://github.com/jolocom/smartwallet-app/releases/tag/v1.6.0

    Read more on it, and check out the demos >> https://app.mailerlite.com/l7i5s7

    sean
    @saifahn
    @huidwd2 Sorry for the late reply, but are you still having this problem? Do you have any more information?
    Volker Schiewe
    @VolkerSchiewe
    @huidwd2 verifyDigestable is taking the publicKey and the digestible as parameters. In your code example it looks like you are using your seed instead of the publicKey. You can generate the publickey based on a seed with the help of the SoftwareKeyProvider. Let us know if this solves your problem.
    Harry Wright
    @hcaw
    Hi all, I'm using the jolocom-lib as an npm module at the moment and would like to access some other classes like Identity, SoftwareKeyProvider etc. Does anyone know if this is possible with the library in its current form? Great work by the way, really impressed with how super tidy the code is
    Mina Nagy Zaki
    @mnzaki
    @hcaw everything is accessible from under the build directory js/
    import { Identity } from 'jolocom-lib/js/identity/identity'
    import { SoftwareKeyProvider } from 'jolocom-lib/js/vaultedKeyProvider/softwareProvider'
    Ellie Stephens
    @EllieStephens

    In case you're curious >> a quick technical explainer from Kai Wagner and Joerg Rueckrieman on how we built our SSI tech into the Xride scooter rideshare system >> https://youtu.be/xuMojUAf6xg

    A full recap from the launch event we attended last week at the Deutsche Telekom Headquarters in Bonn can be found here >> https://medium.com/@Jolocom/decentralized-ride-sharing-launches-in-bonn-3c0cf0cc3795

    Ellie Stephens
    @EllieStephens
    Our devs pushed another significant release this week - this one enabling seed phrase recovery and offline access for the SmartWallet, among other UI/UX and library improvements. Let us know what you think >> https://github.com/jolocom/smartwallet-app/releases/tag/v1.7.0
    Sean
    @blazedarwin

    And that's a wrap! 🎬 We've had a fantastic 2019 and cannot wait for the new pilots, projects, and real world application for #selfsovereignidentity solutions that 2020 will bring 🎉

    Learn about what we achieved this year and how far we've come in our Year in Review blog post — everything from new product specs to new projects in #mobility and #egovernment. Our team has grown, we've been around the world in events, joined new communities and are extremely pleased to have had a chance to work with so many great companies and communities.

    Read more in our recap here:
    https://stories.jolocom.com/jolocom-2019-year-in-review-7404cec5b47a

    Hidde-Jan Jongsma
    @hidde-jan
    Hi all
    Ellie Stephens
    @EllieStephens
    Hi @hidde-jan ! Sorry for the delayed reply. We are back in the office and back in action after the holiday season. Let us know if we can help you with anything.
    Ellie Stephens
    @EllieStephens

    Our update for January now available: https://app.mailerlite.com/s7u5l1

    As always let us know if you need support or questions answered on our code 👍🏽

    PS We're also hiring! We're currently on the hunt for a Senior Frontend Developer to join our team here in Berlin. If that's you, please check out the link. If not, please don't hesitate to forward: https://jolocom.io/wp-content/uploads/2020/01/Senior_Frontend_Developer_at_Jolocom.pdf
    Johannes
    @iwTGBs

    hi, im trying to make your generic-backend run under Ubuntu
    and also to make an APK Package in Android Studio under Ubuntu of your jolocom wallet for testing purposes. It might be a starters question,
    but may be you can help me, since i have some issues with those tasks.
    Concerning the APK: I got the Source of Github and when prompted i created an Android Studio Project for it.
    Then following Onscreen instructions which left me with 3 directories named: androidTest, debug, and main
    Is that a working valid way to do it or do i have to do it otherwise to get it to work,
    because the package wont get done with an Error referring to: appcompat.theme(missing library?) or am i completely wrong here?

    Referring to the generic backend or in general: should i use node version 10.15 or is a higher version also fine to work with?

    Mina Nagy Zaki
    @mnzaki
    Hi @iwTGBs
    there should already be an android studio project under smartwallet-app/android and you should just use that one, don't create a new one!
    As for generic backend, it should work with node v10+, we'll update the README with that info :)
    Johannes
    @iwTGBs
    Good Morning. Short question: Ist it possible for me if i set up a Frontend to connect to the backend, that i firstly get back an QR Code from the backend and eventually but not necessarily, as it would require the app to be acessible to me in a way i presume wouldnt work in an local development network, authenticate via the QR Code in the confined spaces of my local development network? Only for testing. Though most important point for me would be to know if getting the Qr code works.
    Mina Nagy Zaki
    @mnzaki
    @iwTGBs morning!
    Can you clarify a couple things?
    • What do you mean by "Frontend" and how is it different from the "Backend"? In context of our usual flows, there's a nodejs backend that also serves a simple HTML/JS frontend (which sometimes talks to the backend over WebSockets but can also just do normal http)
    • What are you assuming wouldn't work in local dev envs?
    Johannes
    @iwTGBs
    @mnzaki Thank you for you patience. Let me rephrase. I hope it will make it clearer. The basic thing we would like to do is: that we have a Frontend service (webpage without own identity management) where we would like the User to be able to Log in/Verify with the Jolocom Wallet where the Identity is stored. We assume it would work via Qr Code for example or other means of confirmation . We also assume that the generic backend then sends necessary information to the wallet . We assume we need the Backend in between for all that. The Question is how that communication is done between Wallet , generic Backend and Frontend Service. Right now im trying to set up a Webpage that is simulating that process to see how we could use that.
    Mina Nagy Zaki
    @mnzaki
    @iwTGBs
    • There's a bit of a security issue if your frontend and backend are not served by the same server
      • You have to authorize the frontend to the backend, or in some way verify that only authorized frontends can create QR codes (which are just a means to transport interaction tokens) and pass them on to the wallet.
      • Optimally the wallet should never callback into a "frontend", always directly contacting the backend
    • You do need some identity-capable entity of course to be able to do any interactions
    • The generic-backend is not necessary as a middleman. Any service that you already run (using nodejs of course, since we don't yet have bindings for other languages....) can maintain and use its own identity.
      • Do you have your own service that you are trying to authenticate/login users into? The wallet should talk to it directly (via the right callbackUrl in the interaction tokens)
      • Your service can then issue interaction tokens (as QR codes) directly, and it can do the generic-backend's job
        • this basically means using the generic-backend as a template to start your project from, and adding your own use-case specific code in there
        • at some point we are going to release an expressjs plugin for easy SSI integration, instead of distributing the generic-backend
        • If you already have your own services and you still want to use a separate backend (the generic-backend) to manage SSI interactions, then make sure you create trusted and secure connections between your services and the generic-backend!
    Mina Nagy Zaki
    @mnzaki

    @iwTGBs: that i firstly get back an QR Code from the backend and eventually but not necessarily, [...], authenticate via the QR Code in the confined spaces of my local development network?

    Not sure if this is clear but:
    To "authenticate via the QR code" the wallet will actually send HTTP requests to the backend that issued the interaction token that is encoded in this QR code, so you absolutely need the wallet to have access to the backend

    Johannes
    @iwTGBs
    @mnzaki Our service is not a server side frontend its running locally in an electron app / browser and its not accessible on the internet. therefore we need to have some server side component and we thought the backend could be that, meaning the backend keeps websockets open to both the wallet and the frontend client. Thus enabling the communication between both (Wallet and Frontend Service).
    Mina Nagy Zaki
    @mnzaki
    @iwTGBs but is your app entirely local-first? I mean you don't have any global services/backends/servers etc?
    also if your project is open source I would really appreciate taking a look :D
    Johannes
    @iwTGBs
    @mnzaki The application is "entirely and mostly" local first. At least for the purpose of authentication between wallet and frontend. Once the identity is logged-on to the frontend (which basically means that the user has demonstrated that he is in posession of the private key of the identity via the wallet and not some identity-impersonator), the frontend (which is the client UI and business logic) then is capable to log-on to a cloud service which provides the transactional data to be run/processed in the frontend client. Note : The identity (DID) needs to be pre-approved in the cloud-service by a separate permissioned process. Concerning taking a look at the source code: Yes, we will open-source the frontend in the future but its not yet done. Nevertheless we really would like to have a chat with you if it´s possible (Skype / Zoom or other means). For better mutual understanding of what we are doing ( Integration of your wallet) and regarding our requirements for your wallet for our next steps with our frontend / cloud-service.
    Johannes
    @iwTGBs
    @mnzaki You might want to know who you are talking with. For that purpose I´m giving you the link to the company´s web/online representation. So you can get sort of an insight /impression. https://difacturo.com/
    Mina Nagy Zaki
    @mnzaki
    @iwTGBs hey! I will try to arrange for a call soon, but apologies we are kind of busy with various things right now
    Johannes
    @iwTGBs
    @mnzaki👍
    Johannes
    @iwTGBs
    @mnzaki Hey. Following Problem: with the Swimming Pool example. Redis server is running properly. BUT: Backend Server doesn´t start. Im checked out with "git checkout feature/aKaartIntegration" as described in the Documentation and am using that standard configuraiton without change. On console logging in "server.ts" it gives me the following error when i start the backend server manually(manually, because it doesn´t start it with yarn start). Hallo
    SoftwareKeyProvider {
    encryptedSeed:
    <Buffer 78 9e 02 4e 4a 3f d4 44 f4 50 a1 1c 97 9d 3a 86 c1 8c c7 d4 62 a0 3e 58 11 f7 8e fe 10 c3 20 c4 ee 04 71 61 a6 e2 08 1b 1c 0f 1c 00 70 3c 42 54> }
    (node:17865) UnhandledPromiseRejectionWarning: Error: Could not retrieve DID Document. Returned error: project ID is required
    at JolocomRegistry.<anonymous> (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:172:31)
    at step (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:32:23)
    at Object.throw (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:13:53)
    at rejected (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:5:65)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    (node:17865) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
    (node:17865) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. What can i do about that?
    Using standard Login aaaaaa * 64 and battery horse staple that was provided
    in config.ts
    chunningham
    @chunningham

    Hi @iwTGBs, this is caused by that branch using an older version of the library which uses a since-deprecated Infura API. To solve, I would recommend either using the master branch of the generic backend or upgrading your jolocom-lib dependency to 4.0.1. The master branch should still work for the swimming pool as long as you keep the same config.ts file, however some type definitions may have changed slightly, e.g.:

    /* Credentials required during authentication */
    export const currentCredentialRequirements = ['a-kaart']
    
    export const credentialRequirements = {
      'a-kaart': {
        metadata: demoClaimsMetadata.akaart
      }
    } as { [key: string]: ICredentialReqSection }
    
    /* Credentials offered by the service. */
    export const credentialOffers = {} as {
      [key: string]: {
        schema: BaseMetadata
        metadata: {
          renderInfo?: CredentialOfferRenderInfo
          metadata?: CredentialOfferMetadata
        }
      }
    }

    The main changes on the aKaartIntegration branch are related to integration with an external service via adding custom middleware, so it is still a good example of that.

    Johannes
    @iwTGBs
    @chunningham i stayed on the akaart branch and updated the dependency to 4.0.1 keeping the config.ts as follows(in first snippet) and changing specified area to your new code example. He cant find CredentialOfferRenderInfo and CredentialOfferMetadata thus "yarn build " throws 8 errors.
    image.png
    Mina Nagy Zaki
    @mnzaki
    @iwTGBs that branch is really old, trust us on this one :D it's something for an old demo, and some things have changed since.
    I think a more plausible solution would be to merge master into into it to get it up to date, if you really insist on using it
    though a much better solution is as @chunningham outlined in https://gitter.im/jolocom/SmartWallet?at=5e56488cd7bb4e179ca1b614
    Johannes
    @iwTGBs
    where do i find more documentation on how the backend is connected to qr code implementation / functionality?
    Johannes
    @iwTGBs
    and/or could i get your avalon related backend configuration e.g. "config.ts" to understand it or the whole backend .tar file ;-P?
    agruener2000
    @agruener2000
    Hi, on which Ethereum network is Jolocom connecting and creating the identities?
    Johannes
    @iwTGBs
    @mnzaki after the wallet sends the POST request and the data the frontend requested to the backend, does the backend automatically send it back to the frontend ?
    or do i have to configure the middleware route.ts or somth*?
    Mina Nagy Zaki
    @mnzaki
    @agruener2000 hi! sorry for the very late reply......
    We're on rinkeby network. You can find that information in the jolocom registry code: https://github.com/jolocom/jolo-did-method/blob/master/jolo-did-registry/ts/index.ts
    Mina Nagy Zaki
    @mnzaki
    @iwTGBs it's not exactly automatic, there is some code to do that in the generic backend
    Which flow are you implementing?
    In either case there is a point at which this happens: await setStatusDone(redis, nonce)
    This is important because it triggers the code here to run: https://github.com/jolocom/generic-backend/blob/52765fdf15b8a5e9f840b269b927aa0eb477bac9/src/sockets.ts#L80
    which will send data through the socket, and I think that's what you are missing!
    This code is triggered by changes being made to redis (that's basically what watchDbForUpdate is for)
    Johannes
    @iwTGBs
    which one of the two is used if Frontend requests email on authentification , as defined in config.ts with / Credentials required during authentication /
    export const currentCredentialRequirements = ['email']. i assume thats the setting if an /authenticate/ get request comes in. wallet scans code and sends email to backend for pass to frontend . is that CredentialShare or CredentialOffer.
    Mina Nagy Zaki
    @mnzaki
    That is actually for CredentialShareflow on the wallet, which is used in the controllers/registration.ts code.
    Note that the backend code does not send any data or credentials back to the frontend after success!
    You must do that manually if you want/need to.
    The backend will only send a success message over the websocket
    Johannes
    @iwTGBs
    The backend will only send a success message over the websocket
    does it send that back to the Frontend? because in that case my Frontend doesnt even receive a success message while its listening.
    agruener2000
    @agruener2000
    @mnzaki Thanks a lot!