search

AxLabs / grantshares

GrantShares Program 🌱
https://grantshares.io
Apache License 2.0
22 stars 3 forks source link

Renewed iOS SDK #18

Closed grantshares-dapp[bot] closed 1 year ago

grantshares-dapp[bot] commented 1 year ago

Abstract

The project in this proposal looks to create a new and updated iOS SDK to facilitate interaction with a node on the Neo Blockchain. The SDK will implement the following the functionality: key importing and generation, basic transaction signing, selected RPC API read requests.

Proposal Information

Description and Goals

Having a range of options for users to interact with the Neo blockchain via mobile devices will be crucial for the ongoing growth of the Neo community. The proposed SDK would allow the creation of both open and closed-source iOS applications (e.g. wallets). Having a larger range of options for users will also increase competition and innovation within the space that will directly benefit Neo users. The need for an updated iOS SDK is even noted on the Neo General Grants page with the “High” priority label.

There is an existing iOS SDK for Neo (neo-swift), however this has not been maintained and is currently not passing build with the latest version of Swift. Although the functionality is similar, this proposal will update the project to the Neo N3 standard, as well as writing the framework in the latest (5th) version of Swift. It also aims to modernise the framework in other ways, such as aiming to achieve the cryptography functionality natively in Swift (the current DSK uses transpiled Go) and distributing via the Swift Package Manager, rather than solely Carthage.

The main features to be included in the initial version are: key import and generation, transaction signing and RPC read requests. The main anticipated challenge is implementing the cryptographic methods natively in Swift 5. In the worst case scenario the project will have to use transpired functions from a different language. However, I am currently researching Swift options and believe that the requisite cryptography can likely be implemented natively.

Deliverables & Roadmap

The roadmap for this project is for a single final deliverable

  1. Project Design - approx. 30 hours

    • Formalise specification
    • Design and reconcile object classes
    • Confirm framework architecture
    • Project setup - create initial models, types and constants within project

  2. Key Generation - approx. 50 hours

    • Complete research of Swift-native cryptography capability
    • Implement secure private key generation
    • Account information derivation (WIF, Public Key, Address)
      • Implement base358 check encoding
      • Implement Neo secp256r1 ECC algorithm

  3. Key Importing - approx. 20 hrs

    • Adapt cryptography to derive account information from a given raw hex private key or WIF private key

  4. Node and network selection - approx. 20 hours

    • Develop base classes for API that handle configuration
    • Create interface to configure api to use MainNet or TestNet
    • Create interface to specify the node to be sent the API requests

  5. Transaction Signing - approx. 90 hours

    • Create data models and types for the components that are required for transactions
    • Develop boilerplate for building transaction scripts
      • Transaction attributes
      • Gas calculations
      • Payload construction
      • Transaction serialisation and signing
    • Test transactions via SDK for a full range of test cases

  6. Blockchain read API interface - approx 40 hours

    • Develop API boilerplate to facilitate RPC API calls
      • Request construction
      • Standard parameter configuration
      • Error Handling
    • Create methods for selected RPC API calls

  7. Test coverage - approx. 80 hours

    • Write unit tests for each distinguishable component
    • Complete end to end tests for a comprehensive range of use cases

  8. Documentation - approx. 30 hours

    • Write documentation for each user-facing component
    • Documentation should cover each reasonable use case
    • Document should provide overview of configuration options
    • Documentation should cover each usage method where multiple exist for a component

Total Budget: approx. 360 Hours @ $100/hr = $36,000 ≈ 3,000 NEO @ ~$12

Work will be carried out on a part-time basis at roughly 20 hours per week, taking a total of 4 to 5 months.

Deliverables Verifiability

The scope of this proposal is ultimately a single deliverable. As such the verification of the deliverable will be based on whether the following is delivered.

  1. A stable open-source iOS SDK implementing the outlined features with high test coverage
  2. Accompanying documentation demonstrating the usage of all implemented features

Budget Plan

The budget for this project solely supports the man-hours spent developing the SDK as there are no other needed resources with any cost. Development hours and rates are listed in the roadmap.

About You

Ben Gray https://github.org/crisogray

I’m an independent iOS developer that’s successfully launched two apps and completed a third, crypto rebalancing app, with a focus on architecture, as part of a university project. One of the apps I released reached #3 in the paid social media in the UK App Store charts and had hundreds of users. I’ve also developed iOS prototypes for idea-stage startups and have advised the same startups more generally regarding their technology strategy. I have had a growing interest in crypto since 2016, wanting to apply development skills to blockchain and contribute to exciting projects. Neo in particular is a highly innovative project which I believe will continue to grow thanks to its active development team and engaged community; it’s a project to which I’d be excited to contribute.

Proposal Info :clipboard:

[ {
  "target_contract" : "0x6276c1e3a68280bc6c9c00df755fb691be1162ef",
  "method" : "releaseTokens",
  "params" : [ {
    "type" : "Hash160",
    "value" : "ef4073a0f2b305a38ec4050e4d3d28bc40ea63f5"
  }, {
    "type" : "Hash160",
    "value" : "62e4e06e12988a33cf1676d61df8ff9e74f6025c"
  }, {
    "type" : "Integer",
    "value" : "3000"
  } ],
  "call_flags" : 15
} ]

👇 React with 👍 if you liked it, or 👎 if you think this proposal can be enhanced!

lock9 commented 1 year ago

Hi. Unfortunately, I'm not in favor of this. My opinion:

Sorry :(

gsmachado commented 1 year ago

@crisogray

Some questions from my side:

1) We, from @AxLabs, know that developers prefer to develop native applications on iOS (Swift) and Android (Java/Kotlin) rather than using frameworks IF (and only IF) the apps require to reach some minimum level of performance. Thus, depending on the use case, this might be interesting. For example, if you're developing a wallet, not resource intensive at all, no need to develop a native iOS app. On the other hand, if you are a gaming studio developing blockchain-based games for mobile, native apps might be required. Thus, based on this point, my questions are: a) how many gaming apps do we currently have in the Neo ecosystem? b) if we don't have much, how many gaming studios could we onboard if we also have the iOS SDK easy to be plugged in? (FYI, for Android, @neow3j already covers that)

2) Are you from the Neo community? Can you share a bit more about how did you get to know Neo?

3) We can't evaluate your track record from your GitHub profile nor from the things you wrote in the About You section. Do you have a couple of links that might help us? For example, provide links to things you developed or have done in the past.

crisogray commented 1 year ago

Hi both,

Thanks for the quick responses and good points/questions

@lock9 To answer your points first

You can use Neo on iOS, using neon-js. It also works with React Native, native Android and Flutter.

I agree with you in that for anyone who’s looking to create an iOS app using React Native or Flutter then absolutely, yes, neon-js is sufficient. However I think for many of those that are writing, or going to write, apps natively for iOS, using neon-js alongside Swift (to the extent that it is possible) would be uncomfortable. Following that, I personally think that a standalone Swift implementation is justifiable from a developer preference standpoint (as mentioned in @gsmachado ’s reply), but then I am bias a Swift developer. Also, and I don’t particularly aim to reference this but it I think it’s relevant, the Neo General Grants does mention an iOS SDK, so I would like to think at least someone at Neo would agree with me.

I found it very expensive.

That’s fair enough. I think the cost vs. benefit and cost vs. market can and very much should be considered. However, I stand by my costings in this case. Working as a freelancer and given the complications and roadblocks that occur on projects of any size my rate includes the “undocumented hours” that go in. Feel assured that with this proposal comes my commitment to delivery to the absolute best of my ability, not just the fulfilment of the listed hours. But of course I understand that even with that said you could feel it is too expensive. If that is the consensus of those in a position to progress/reject this proposal then that is a conclusion I accept.

There is no evidence that having another library will bring users or projects.

This is the point I’d say I disagree with the most. The point on face value I think is probably true in that this won’t attract a large number of developers, but I believe this sort of developer tooling serves a fundamentally different purpose to that. I believe it is less-so about the attraction of new developers, I don’t think any SDK alone would be particularly powerful in this regard, but about the options with which they are presented when they arrive. Personally, I believe that for long-term competitiveness of the ecosystem, comprehensive developer tooling will be a definite advantage. In the same way that the usability of wallets improves user experience and thus retention of the protocol itself, the abundance and quality of developer tools works much the same way for developer experience. Back to your original point, yes this won’t necessarily bring in new developers in droves (though I don’t think any SDK does) but it will improve the tooling for a specific set of developers that do bring their ideas to the Neo ecosystem.

Thanks again for your response, and do follow up with any responses or questions.

In response to @gsmachado ’s questions

We, from @AxLabs , know that developers prefer to develop native applications on iOS (Swift) and Android (Java/Kotlin) rather than using frameworks IF (and only IF) the apps require to reach some minimum level of performance. Thus, depending on the use case, this might be interesting. For example, if you’re developing a wallet, not resource intensive at all, no need to develop a native iOS app. On the other hand, if you are a gaming studio developing blockchain-based games for mobile, native apps might be required. Thus, based on this point, my questions are: a) how many gaming apps do we currently have in the Neo ecosystem? b) if we don’t have much, how many gaming studios could we onboard if we also have the iOS SDK easy to be plugged in? (FYI, for Android, @neow3j already covers that)

Before answering the actual questions, I think the ‘IF and only IF’ part can be expanded, and there are larger number of developers that could be inclined to develop natively than it might seem. It is true that when assessing which tools to use to make an app, the cross-platform argument often wins out, leading to choosing React Native or Flutter. But I believe there are a number of other categories that are worth thinking about. First, are those developers that are experienced in iOS specifically and are only in a position to create something for iOS, i.e. going cross-platform would be a huge change-up from their normal work. Secondly, there are teams that may choose to develop natively for other reasons, perhaps they need to access specific native libraries or they have very specific design features that can only be implemented natively. I accept that this is small cohort but I believe it certainly exists nonetheless. Thirdly, as you said, apps that need to be particularly performant, Finally, the category that I think represents a reasonable number of developers and one of the reasons I believe this proposal (and this sort of proposal in general) is still justified is the large number of apps that exist already using native development. Any iOS developers that have existing apps and that would like to adopt Neo are forced (as @lock9 said) to import a JS library. This is where I believe most iOS developers would have an issue as per my first response.

Anyway, in answer to your actual questions, I’m not hugely in tune with much gaming stuff but from what I gather there are currently a handful of prominent games within the ecosystem with a decent number of transactions. When it comes to onboarding the number of game studios becoming active is obviously growing rapidly. Of those that come to Neo, not all of them would necessarily choose native iOS but for those that did, this SDK would implement the requisite base functionality with accompanying documentation to make the onboarding as easy as it can be. When it comes to onboarding more broadly, as per a previous response, I think it is difficult for an SDK to do this in and of itself but I’d want for the developers that do look to build in the ecosystem to be greeted with a wide range of quality options.

Are you from the Neo community? Can you share a bit more about how did you get to know Neo?

I’ve been interested in the space for several years and am a long time lurker of a few projects, including Neo, which I’ve known about since it was known as AntShares. It came back onto my radar properly with the N3 upgrade. I like to think of the Lindy effect and I think the fact that Neo has been around for so long whilst continuing to develop and grow is a fantastic sign of strength and drew me back in with more intensity. That being said, I’m far more of a lurker than someone talking in the various channels so I’m not known in the community, but my interest in Neo is long-standing and I’d be excited to get involved.

We can’t evaluate your track record from your GitHub profile nor from the things you wrote in the About You section. Do you have a couple of links that might help us? For example, provide links to things you developed or have done in the past.

Sure, my two main apps were SoFlow and Tabb. SoFlow was the more successful of the two which reached number 3 in its category for paid apps in the UK, but I believe Tabb is the better app technically and has a better design. Both apps are unfortunately deprecated as both were dependent on social network APIs which have all since been heavily reduced in scope. A project from my GitHub that I think is especially relevant is BalanceBot, an iOS app produced academically. It is a crypto portfolio rebalancing app and I believe is the best showcase of my ability as it has such a strong focus on good architecture. The dissertation I believe is also interesting if you want to have a look at the abstract and glance at what it was about.

Thank you both again for the responses, please do follow up as I think the discussion is incredibly useful

lock9 commented 1 year ago

Hello,

I agree with you in that for anyone who’s looking to create an iOS app using React Native or Flutter then absolutely, yes, neon-js is sufficient. However I think for many of those that are writing, or going to write, apps natively for iOS, using neon-js alongside Swift (to the extent that it is possible) would be uncomfortable. Following that, I personally think that a standalone Swift implementation is justifiable from a developer preference standpoint (as mentioned in @gsmachado ’s reply), but then I am bias a Swift developer. Also, and I don’t particularly aim to reference this but it I think it’s relevant, the Neo General Grants does mention an iOS SDK, so I would like to think at least someone at Neo would agree with me.

One option is to wrap neon-js on swift code, making it transparent for the end user. I'm a mobile developer myself. I started on iOS when you had manual memory management (reference counting). I saw the rise and fall of HTML 5 and other similar technologies. As a developer, I preferred native iOS development (objective-c and later swift), but especially for an SDK, we should use a cross-platform solution. The reason that other technologies failed to take over native code was related to UI performance (responsiveness). This is not the case for an SDK.

This image exemplifies it: image

It is very easy to use Neo features on a mobile app, native or not. If you ask me if we should build a native app or a cross-platform one, I would vote for the native app, but not for an SDK. I'm in fact against having two SDKs for mobile. I know from experience that this will lead to inconsistent behavior. Also, the method signatures will be different, making it harder for developers to assimilate them. Different method signatures, with different documentation.

In conclusion, all I can say is that I don't think we need something like this. We could build a wrapper if that is the case. The reason that the library didn't receive any updates, was because literally 0 people asked for it.

lock9 commented 1 year ago

As a second comment, I want to say that I'm ok with the hourly price. As a community member, I would like to work with you. There is the problem of building an SDK using swift, however, maybe there is room to build the wrapper or similar solutions.

If you want to go "Full Apple", then we should come up with something that uses their latest features. For example, if they are launching VR later this year, we could build something for it. I'm saying this because that can justify an 'iOS project', and not a cross-platform one. Projects using these latest features in a meaningful way draw attention from both early adopters and Apple.

crisogray commented 1 year ago

Thanks again for your response with further detail.

I can see and appreciate that a from-scratch SDK solely for iOS could be not entirely justifiable and result in a duplication of efforts. I do still like the idea of a Swift wrapper/bindings for the neon-js node module, perhaps in a similar manner to this, and think it could bring real convenience to developers whilst maintaining the positives you mentioned of the js library. I’d be interested in submitting a modified and reduced proposal to this end, as I think it could offer the best of both worlds, whilst being better value-for-money. I’m interested in your, and everyone else’s, thoughts on this as I hope it could be a positive direction for this to take, thanks again.

gsmachado commented 1 year ago

@crisogray great to hear.

So, at this moment we don't have a mechanism to "edit" submitted proposals.

But, before re-submitting a proposal, I suggest waiting a bit more to get more feedback from the community -- maybe someone else has something else that you could consider for a new submission.

@shargon @lllwvlvwlll @devhawk @JohndeVadoss @steven1227 @igormcoelho @deanragnarok @hacfox @realloc: What do you think about this proposal?

EdgeDLT commented 1 year ago

Hello Ben, thanks for your proposal! I appreciate the detailed breakdown and honest time estimations. Based on the discussion so far, I'm in two minds about this one.

From my perspective, the major selling point for Neo is that any developer should be able to use it to build decentralized applications regardless of their preference for languages, tools, or targeted devices. It meets them where they. With that in mind, I think $30,000 is a small ask when it can be used to make iOS developers feel like first-class citizens when building on N3.

Is releasing a Swift SDK going to trigger a cascade of iOS dApps on the network? Well no, probably not. But this is a development proposal, not a marketing proposal, so directly attracting new developers with it is, as far as I'm concerned, outside the scope. What matters is that if an iOS developer does come across Neo in the future, they will see that they are natively supported, just as Android devs are thanks to Neow3j.

That said, I have to defer to @lock9's experience when it comes to mobile/iOS development, I have none of my own. I can understand that a Swift SDK is perhaps less desirable than using Neon.js, especially for teams that want to build on both major mobile platforms and therefore want access to a standard API. So perhaps Swift bindings for Neon.js would be the more appropriate path forward, unless demand for iOS exclusive apps starts to emerge.

I would like to see some opinions from other iOS developers in the ecosystem on the best way to progress. Tagging @apisit and @WyattMufson as two that came to mind, perhaps one of them will be able to share a little of their time to offer some guiding insight.

WyattMufson commented 1 year ago

I definitely agree with @EdgeDLT here. I disagree with most of what @lock9 said. This really doesn't come off as expensive, it's in line with costs of other proposals and looks like a better use of funds. In my opinion, when developers look to develop on web3 they expect to find robust tooling for their preferred language. Having an SDK for Swift + Kotlin is sort of a bare minimum (like the number of SDKs that exist natively for EVM). And most of the professional grade SDKs I've used that are available for mobile are built natively. As a mobile developer looking to get into Web3 I wouldn't use some JS wrapper in my code, I'd just use a different chain all together.

And I don't think the comment on neo-swift not having users because no one wanted it was very accurate. It was wrapper of a golang library neo-utils that the original O3 team wrote and hasn't been touched since 2018 and there's no way something not getting maintained is going to get used. There really isn't a good example of a purely Swift implementation.

gsmachado commented 1 year ago

I definitely agree with @EdgeDLT here. I disagree with most of what @lock9 said. This really doesn't come off as expensive, it's in line with costs of other proposals and looks like a better use of funds. In my opinion, when developers look to develop on web3 they expect to find robust tooling for their preferred language. Having an SDK for Swift + Kotlin is sort of a bare minimum (like the number of SDKs that exist natively for EVM). And most of the professional grade SDKs I've used that are available for mobile are built natively. As a mobile developer looking to get into Web3 I wouldn't use some JS wrapper in my code, I'd just use a different chain all together.

And I don't think the comment on neo-swift not having users because no one wanted it was very accurate. It was wrapper of a golang library neo-utils that the original O3 team wrote and hasn't been touched since 2018 and there's no way something not getting maintained is going to get used. There really isn't a good example of a purely Swift implementation.

Based on my experience (not only on Neo but in other chains), I agree 💯 with @WyattMufson as well ☝️.

And it goes in the direction of what I mentioned here.

Neo already has a native Kotlin/Java SDK for Android (@neow3j). The missing piece is Swift to cover iOS in a proper way.

lock9 commented 1 year ago

We need an iOS SDK, but we can't have just one using Swift. We need a swift wrapper, but not a full SDK.

I definitely agree with @EdgeDLT here. I disagree with most of what @lock9 said. This really doesn't come off as expensive, it's in line with costs of other proposals and looks like a better use of funds. In my opinion, when developers look to develop on web3 they expect to find robust tooling for their preferred language. Having an SDK for Swift + Kotlin is sort of a bare minimum (like the number of SDKs that exist natively for EVM). And most of the professional grade SDKs I've used that are available for mobile are built natively. As a mobile developer looking to get into Web3 I wouldn't use some JS wrapper in my code, I'd just use a different chain all together.

How would you know if you are using a JS, C/C++, or Go if you are using Swift? I can't agree with that argument. I've never seen someone complaining about a dependency made using this or that technology. Developers don't care, they just want to plug it and use it.

Having a Swift + Kotlin is the bare minimum. And we are going for the minimum (with this proposal). We need a cross-platform, mobile, SDK. The user will see a swift library, and unless he digs into the code, there is no way he will know if we are using any other programming language. It can produce a binary that makes the technology behind it invisible to the user.

What about flutter, react-native, and unity developers? Any reason we are giving preference to native iOS developers? React Native and Flutter have around 70% of the mobile market, and we are leaving them out. Why?

WyattMufson commented 1 year ago

Sure developers generally don't care what language it's developed in. That being said for native iOS development it's a lot harder to use SDKs that aren't targeted towards iOS. It leads to a number of different build issues especially when iOS, Swift or Xcode is updated.

On the blockchain side of things developers are going to want to be able to look at the source code in the language they're developing in. It's part of why it was hard to support development of neo-swift and neo-utils, since it was maintained in a different language than what the developers were using and you couldn't step through the code in Xcode.

For developers doing cross platform, they already have a solution — it's neonjs.

And Unity developers are going to want a C# SDK to integrate. This is the whole point, right? Having an SDK for all of the most common platforms (web, mobile, cross platform, game engines). A robust set of tools is something Neo is going to need to support developers that consider using it.

lock9 commented 1 year ago

Hi @WyattMufson ,

That being said for native iOS development it's a lot harder to use SDKs that aren't targeted towards iOS. It leads to a number of different build issues especially when iOS, Swift or Xcode is updated.

That is not true, why would it be harder for developers to use it if it is written in Swift (or objective C)? We can't assume that a broken build is an issue either. At least, we need to consider that the project will work. CI/CD can be used to overcome cross-platform building. We can even ship the binaries if we have build issues.

On the blockchain side of things developers are going to want to be able to look at the source code in the language they're developing in. It's part of why it was hard to support development of neo-swift and neo-utils, since it was maintained in a different language than what the developers were using and you couldn't step through the code in Xcode.

I don't think that it is the goal of this project to teach developers how Neo works. Also, about maintenance: if there is one thing that these cross-platforms solutions are good for, is the reduced time required for maintenance. There is a lot of evidence to support this claim.

WyattMufson commented 1 year ago

The pros of cross platform are easier maintainability. It comes at the cost of usability, customizability and compatibility. Developers will have a harder time understanding how the underlying code works with solutions that are written in another language and then compiled. I learned this with using neo-utils first hand. It was hard to debug issues without help from @apisit.

There's an existing native Android SDK. There is no native iOS SDK. Building some brand new cross platform SDK sounds a bit over engineered.

lock9 commented 1 year ago

The pros of cross platform are easier maintainability. It comes at the cost of usability, customizability and compatibility. Developers will have a harder time understanding how the underlying code works with solutions that are written in another language and then compiled. I learned this with using neo-utils first hand. It was hard to debug issues without help from @apisit.

There's an existing native Android SDK. There is no native iOS SDK. Building some brand new cross platform SDK sounds a bit over engineered.

Is the goal of this project to teach people how Neo works? What about the other platforms? Why is it ok for a flutter developer to add neon-js but it is not for an iOS developer?

WyattMufson commented 1 year ago

Is the goal of this project to teach people how Neo works?

I don't understand where this comment is coming from. Might suggest re-reading what I wrote. There is no relationship between understanding how the code you are using works and teaching people how Neo works.

What about the other platforms?

Is this thread not about a native iOS SDK?

Why is it ok for a flutter developer to add neon-js but it is not for an iOS developer?

This goes back to my original point of what bare minimum mobile support looks like. Support the mobile platforms natively and then add from there. This is a classic example of over engineering, trying to make a one size fits all solution that no one wants.

@lock9 I have no interest in debating you. We've made our points. Let others chime in with their opinions.

gsmachado commented 1 year ago

Let me state, again:

There's a missing part of the puzzle, not covered by anyone in our community: the lack of a good native iOS SDK. 💯

I feel that a good native iOS Swift SDK is a great foundation that enables lots of things ON TOP of it.

If react-native devs would like to wrap around the native iOS SDK, great, it's based on a solid foundation. If flutter devs would like to wrap around the native iOS SDK, great, it's a solid foundation. If Go devs would like to wrap around the native iOS SDK, great, it's a solid foundation. If Swift guys would like to build something natively, great, the native iOS SDK would be already there! If react-native, Go, or flutter devs would like to wrap around neon-js SDK, great, they can also do it!

Something that people often neglect: once someone takes ownership and raises the flag of a specific technology, most likely this person/group will get other devs on this tech ecosystem to start developing with it.

That's what happened when @AxLabs took ownership of native Java/Kotlin/Android. We felt passionate to educate and guide projects using Java/Kotlin/Android to join Neo.

gsmachado commented 1 year ago

I just finished listening to the podcast @JohndeVadoss recently participated in, and he said: "how do you motivate these 22+million devs [estimated amount of devs the world has] to our platform? well, you give them the tools... the languages, the dev experience they are used to"

lock9 commented 1 year ago

I don't understand where this comment is coming from. Might suggest re-reading what I wrote. There is no relationship between understanding how the code you are using works and teaching people how Neo works.

I'm based on this comment here:

Developers will have a harder time understanding how the underlying code works with solutions that are written in another language and then compiled. I learned this with using neo-utils first hand. It was hard to debug issues without help from @apisit.

Nobody should need a developer to teach them how to use the SDK. That is not a normal situation, we should try to avoid it. But if we have different code, for different platforms, doesn't that make the problem even bigger?

Is this thread not about a native iOS SDK?

Yes. An 'iOS SDK' means an SDK that can be used to build apps that run on iOS. A swift SDK will solve the problem for native iOS developers. Not all iOS developers use swift. Many uses React Native, Flutter, or others. They do this because although they prefer iOS development, sometimes you just need to get into the Android market. I can tell this from experience: We used react-native for our mobile wallet. I didn't want to, but that was not my decision.

@lock9 I have no interest in debating you. We've made our points. Let others chime in with their opinions.

I'm debating the proposal. I'm being direct, but I don't mean to be rude. I have real experience with this, a full swift SDK is a waste of resources. In the short, medium, and long term. I'm strongly against making a full SDK using swift. I have over 10 years of experience with iOS development (+7 for Android). I look at this and think: 'they are trying to solve a problem, but they're just creating a bigger one instead'.

Let me present you Harry's diagram: image Source: https://github.com/ngdenterprise/design-notes/blob/master/neofx-layers.png

As we can see, shared layers are reused by the SDKs. The same concept can be applied here. I'm proposing a different solution to resolve the iOS SDK need. You can expect senior developers to have cross-platform needs.

My proposal is something like this: image

I've seen this, but I am not sure if it would work for us: https://kotlinlang.org/docs/multiplatform.html#kotlin-multiplatform-use-cases We could have a core library made in Kotlin. That could be a solution, but it is on Alpha.

This will take less time to create and maintain. It will also solve the problem for a much larger audience.

"Why can't we have the iOS SDK in Swift and create the wrapper for other platforms?" Because of the increased maintenance cost. Let me provide you with real Neo-world examples:

On all our libraries, you can expect to find something like this: isAddress(string: Address) : Boolean

The problem is: Neon-js is compatible with both Neo Legacy and N3. In the past, this method was transformed into:

isAddress(string: Address, isN3: Boolean = false) : Boolean

The result was: that during a large period, people would just use it without parameters. Changing it to N3 would be a breaking change, and decided to avoid that. After N3 started being used, we noticed that many new developers were using it incorrectly. Atomic wallet is an example. Their wallets were unable to transfer N3 assets due to that. I can imagine that the developer has no idea of what Neo Legacy is. He couldn't imagine that the isAddress function should be called with an extra parameter.

We changed it, now it is like this: isAddress(string: Address, isN3: Boolean = true) : Boolean

This was updated only on the N3 branch, so it doesn't affect other releases, however, imagine if we had the same methods on different libraries (iOS / Android). Since different teams maintain them, they won't be updated simultaneously. Then, this situation would appear:

SDK 1: isAddress(string: Address, isN3: Boolean = false) : Boolean SDK 2: isAddress(string: Address, isN3: Boolean = true) : Boolean

SDK 1 would get the updates before SDK 2. An innocent developer may use the 'latest' version of each SDK, and get different results. Possible results: financial loss, app unusable (no transactions would pass, like on the Atomic wallet). There is no reason to believe that we won't have methods with similar signatures and different behavior.

how do you motivate these 22+million devs [estimated amount of devs the world has] to our platform? well, you give them the tools... the languages, the dev experience they are used to

That is why we should consider Flutter, React-Native, and other iOS developers. On mobile development, it is normal to have the same developer working on the app on multiple platforms. Or even on the same team. Imagine two developers working on the same issue, with different SDKs. They won't be able to help each other.

apisit commented 1 year ago

I'm in favor of a dedicated iOS SDK written in pure Swift. I'm still using Swift daily and would love to use this library. @WyattMufson already stated all the pros.

Back in 2017 when we started building O3 wallet. There weren't many cryptography related libraries in Swift. I happen to know and use Go. Building neo-utils in Go and using go mobile to compile to static library for iOS and Android was a very obvious choice for us. It worked. However, It was quite challenging to debug. Imagine not able to step through the function. So we gradually moved lot of things to native Swift later on. e.g. transaction builder, signer, etc.

@crisogray, An additional comment for documentation — It would be great if you could include writing tutorials on neo developer portal.

csmuller commented 1 year ago

@lock9 I understand your vision of the "SDK ecosystem" and I must say it is rather bold ;) Having a common basis on which to build different platform SDKs sounds enticing and allows changes at the core to more consistently bubble up to the top level APIs that then reflect the changes to the developers. This alleviates the pain of making sure that every SDK has implemented the blockchain logic correctly and maintaining that logic not only in one place but in many.

One argument that speak to me when it comes to implementing a native Swift SDK is that the developer will be able to debug into the SDK easily and understand the SDKs code. Optimally, the dev does not need to understand the internals of a Neo SDK, but, in all the coding work I've been doing for Neo, I've always ended up reading library and Neo core code. I also think that it is not wrong in a decentralized ecosystem to have many scattered implementations of the core functionality which are all maintained separately. But, maybe it's just because I don't have the willpower to go the direction of a common Neo Core SDK.

EdgeDLT commented 1 year ago

I also think that it is not wrong in a decentralized ecosystem to have many scattered implementations of the core functionality which are all maintained separately.

I'm really glad you brought this up because it's been a concern of mine too, @lock9 and I have discussed privately a little on this topic.

I see how in a "best case scenario," a unified SDK can reduce maintenance cost and even reduce the likeliness of bugs. But it also drastically raises the chance that a bug would affect everything and everyone on the network. And if the common SDK goes unmaintained, we are back to square one. Developers will have to fork it and compete to be the "new core SDK" or simply start reimplementing features natively anyway. It's not a silver bullet solution, especially in this type of environment.

We would never accept a single core VM implementation, shared across all node types, or one transaction exploit would brick the whole network. We wouldn't build one core compiler and support other languages via custom AST parsers, or one core compiler bug could make every contract insecure.

The SDK is no different, it is an equally critical component where an error could affect user funds. Variety is the spice of life, and decentralized ecosystems are very much alive. It may be an imperfect, more expensive, even somewhat chaotic approach, but I believe it's also the best choice we have given the trade-offs.

lock9 commented 1 year ago

One argument that speak to me when it comes to implementing a native Swift SDK is that the developer will be able to debug into the SDK easily and understand the SDKs code. Optimally, the dev does not need to understand the internals of a Neo SDK, but, in all the coding work I've been doing for Neo, I've always ended up reading library and Neo core code.

1 - When was the last time you debugged the Bouncy Castle Library? Or the Java internals? 2 - How often, in a lifetime, do you think that an iOS developer checks/debug the native iOS libraries provided by Apple?* 3 - Is the goal of this project to teach the inner workings of Neo? You are working on the SDK. You have interests in this, dApp developers should not care about the internals.
Are we going for "6 hours of debugging can save you 5 minutes of reading the documentation"?

I see how in a "best case scenario," a unified SDK can reduce maintenance cost and even reduce the likeliness of bugs. But it also drastically raises the chance that a bug would affect everything and everyone on the network.

This is a misconception. Having different SDKs will cause the ecosystem to become more vulnerable. Another full SDK is going to provide us with the exact opposite result. It will generate more bugs and make Neo look unreliable.

And if the common SDK goes unmaintained, we are back to square one. Developers will have to fork it and compete to be the "new core SDK" or simply start reimplementing features natively anyway. It's not a silver bullet solution, especially in this type of environment.

This is not true either. If we have more repositories, the chances of one of them not being maintained are higher than a single one. A single mobile developer can maintain the core SDK and bindings, but a native Swift Developer cannot.

We would never accept a single core VM implementation, shared across all node types, or one transaction exploit would brick the whole network.

This is the current situation. If we had 2 implementations, we would have seen this network forked or frozen dozens of times. Do you remember when we had Neo-python? It was widely used and maintained. It failed mostly due to differences it had with the native nodes. Reusing code increases security and stability, not the opposite.

I also think that it is not wrong in a decentralized ecosystem to have many scattered implementations of the core functionality which are all maintained separately.

It is on mobile. It has a different nature than a backend or web SDK. On mobile, you do a single design, 2 platforms will use that. The common features of the SDKs will limit the design and features.

image

Adding extra features to single SDKs doesn't mean they will be usable. Even native ones. The UI designer won't add features that will only work for one platform and not the other. Are they going to leave a blank space on the design? This is not how it works in practice.

*The answer is zero because they are all shipped as binaries. iOS developers never debug the libraries provided by Apple,

gsmachado commented 1 year ago

This is a misconception. Having different SDKs will cause the ecosystem to become more vulnerable. Another full SDK is going to provide us with the exact opposite result. It will generate more bugs and make Neo look unreliable.

Strange. I believe (and observe) the exact opposite in the blockchain industry... 🤔 maybe I need to think a bit more about this.

In the end, I think it's about past experiences people had and core principles in relation to decentralization. Clearly, there are advantages and disadvantages to the dilemma "go native or not, that's the question..."

lock9 commented 1 year ago

Strange. I believe (and observe) the exact opposite in the blockchain industry... 🤔 maybe I need to think a bit more about this.

You don't need to look much: Why do you think many chains reused EVM and other Ethereum/Bitcoin based technologies? Because they know it works, it has been tested.

In the end, I think it's about past experiences people had and core principles in relation to decentralization. Clearly, there are advantages and disadvantages to the dilemma "go native or not, that's the question..."

It is not a question about going native or not. It is about ensuring we are providing a good user experience, reaching the largest audience possible, having fewer bugs, and a lower time to market.

There will be a native SDK. It will reuse code, but it will remain native. image

EdgeDLT commented 1 year ago

If we have more repositories, the chances of one of them not being maintained are higher than a single one.

That's not really a logical way to look at it, IMO. Teams and libraries come and go. But with more repositories, the chance of having some option for whatever you are trying to do with your application approaches 100%. With one common SDK, we instead choose to have one dependency which has the potential to hold the ecosystem hostage. The best case does not outweigh the worst case, we don't have the luxury of pretending it can't happen.

This is the current situation. If we had 2 implementations, we would have seen this network forked or frozen dozens of times.

This is somewhat disingenuous. 2 clients is well understood in the industry as the most insecure setup for a heterogeneous network with BFT-style consensus. The reason is simple; if you assume a 50/50 network split amongst validators, a bug in either node implementation that prevents consensus will exceed the fault tolerance and break liveness. In a homogeneous network, it's just the chance of one failing because there only is one. The risk is halved (not really but take my meaning).

Yet no blockchain developer or researcher argues in favor of homogeneous networks, because they are not in favor of a single point of failure. It is a massive trust oversight in an industry built to minimize trust. At least 3 client implementations, preferably more, is the goal. Ethereum Beacon chain has 4 for consensus.

Also, we do have two implementations, but we do not have a 50/50 distribution of each across consensus nodes, I would assume for the same reason I mentioned above. But NeoGo is fully consensus capable, and its mere existence has helped uncover bugs across every part of the C# core, particularly issues that affect state correctness, which is considered critical for applications.

Put it this way, if a GrantShares proposal came through tomorrow wanting funds to build a consensus-capable Python node using the Mamba SDK, I would want to endorse it, and I don't think I'm the only one.

Sorry for further de-railing the iOS SDK discussion with this tangent, but I think it is relevant to the larger point, which is that diversity is a good thing for anything blockchain related. The raised chance of bugs when having multiple implementations does not make a single point of failure the better option. The attack surface of the latter makes it untenable.

@crisogray, I'd like to know how you feel about maintenance of the project after delivery and what kind of role you envision playing in the ecosystem. Do you see yourself wanting to commit to future development of the SDK after completing your deliverables, possibly reapplying for maintenance grants? Or do you see this more as a hole to plug before moving on to application development? Something else entirely?

lock9 commented 1 year ago

That's not really a logical way to look at it, IMO. Teams and libraries come and go. But with more repositories, the chance of having some option for whatever you are trying to do with your application approaches 100%. With one common SDK, we instead choose to have one dependency which has the potential to hold the ecosystem hostage. The best case does not outweigh the worst case, we don't have the luxury of pretending it can't happen.

What do you mean by keeping the ecosystem hostage? If the code is open source, can't someone fork it if they want to?

This is somewhat disingenuous. 2 clients is well understood in the industry as the most insecure setup for a heterogeneous network with BFT-style consensus. The reason is simple; if you assume a 50/50 network split amongst validators, a bug in either node implementation that prevents consensus will exceed the fault tolerance and break liveness. In a homogeneous network, it's just the chance of one failing because there only is one. The risk is halved (not really but take my meaning).

Yet no blockchain developer or researcher argues in favor of homogeneous networks, because they are not in favor of a single point of failure. It is a massive trust oversight in an industry built to minimize trust. At least 3 client implementations, preferably more, is the goal. Ethereum Beacon chain has 4 for consensus.

Also, we do have two implementations, but we do not have a 50/50 distribution of each across consensus nodes, I would assume for the same reason I mentioned above. But NeoGo is fully consensus capable, and its mere existence has helped uncover bugs across every part of the C# core, particularly issues that affect state correctness, which is considered critical for applications.

This point is valid to some extent. This kind of security is related to network security. This adds another 'integrity check' to the network, but this is not the same problem. Some code must be native, due to security or performance reasons. But what about this: image

Do we need another one? Could this benefit us? I don't see how.

Put it this way, if a GrantShares proposal came through tomorrow wanting funds to build a consensus-capable Python node using the Mamba SDK, I would want to endorse it, and I don't think I'm the only one.

If someone showed up here asking to make a node purely in Python, I would be strongly against it too. Just like this proposal, a solution using pure Python wouldn't be usable. Python doesn't offer the performance needed. Neo-python took a week to sync. That is why mamba uses C++ modules. Mamba works like a python wrapper for C/C++ libraries.
"I want to build a full node using pure PHP". Nope. "But Ricardo, look how many websites are using PHP!" image

Yes, I understand. It is widely used. But the technology won't provide the value someone may be expecting. It may even work, but it doesn't mean it has acceptable performance and is safe to use.

The raised chance of bugs when having multiple implementations does not make a single point of failure the better option. The attack surface of the latter makes it untenable.

The problem with this discussion is that my POV is purely technical. I understand what you are saying: A single SDK will cause a single-point failure. It doesn't have to. A core SDK can be made of just interfaces. No runtime code at all. With that, we would have all the SDKs with identical method signatures. That would be good already (great, to be honest).

Code reuse is always a matter of evaluation. Sometimes we should, sometimes we shouldn't. Sometimes it is the best thing to do, while sometimes it's the only option. It depends. For example: encryption methods. That is not even our code. Any problem there, and we, plus half of the planet, are doomed. However, writing our own encryption methods is way more dangerous.

Going back to the proposal, an SDK purely made in swift won't solve the problem for other iOS developer, using React Native or Flutter. The lack of a unified facade also is very bad for user experience, productivity, and learning.

hacfox commented 1 year ago

What a heated discussion, first of all we have experienced too many issues with the SDK. I'm on @lock9's side.

TBH, At that time, We were eager to get the fastest access to the neo network, there were few SDKs for native Apps, so we wrote a neo-toolkit-go library(private), using go mobile to compile to static library for iOS and Android, which does not have to maintain multiple copies of code (OC/Swift and Java/Kotlin), We refer to go-ethereum do, the code refers to neo-go, and so far it works very well for us. For subsequent developers, I'm sure more will choose how to get into the N3 quickly rather than spend time debugging code or read lot of codes or refer articles.

as @lock9 said, can not agree any more.

At least, we need to consider that the project will work. Also, about maintenance: if there is one thing that these cross-platforms solutions are good for, is the reduced time required for There is a lot of evidence to support this claim.

most developers are not concerned about how to implement, but more concerned about whether the results are correct. I apologize if somewhere contraries to yours.

EdgeDLT commented 1 year ago

Thank you for adding your perspective @hacfox! Please don't apologize, your insight is most welcome.

If the code is open source, can't someone fork it if they want to?

Right! But now the common SDK is no longer common, and wrappers will lose their consistency, which was the point of this unification endeavor. Is that better than having many implementations, where users can pick and choose whatever works best for them? Actually, why must these things be mutually exclusive anyway?

If someone showed up here asking to make a node purely in Python, I would be strongly against it too.

Okay, not Python, bad example, say C++, Java, even TypeScript, where performance is not going to be an issue for a consensus node. My point was that having the extra choice is good. Not just for network security in this particular context, but for accessibility to users who will need to trust your software. I'm inclined to believe the same is true for any kind of secondary implementation of Neo, including SDKs.

A core SDK can be made of just interfaces. No runtime code at all. With that, we would have all the SDKs with identical method signatures. That would be good already (great, to be honest).

I hadn't considered that and I can't disagree with the value of it. It seems like it would be a very useful resource for those maintaining tools. Sounds like you need to team up with Harry on neo-fx!

Overall I don't disagree with what you are describing. But I don't see why it should block redundant implementations of different parts of Neo, which provide a lot of unique onboarding value for developers and applications. Everyone can have their cake, can't they?

The stable tools chosen and trusted by application developers will emerge naturally based on their needs and preferences. I see no good reason to prevent one approach in pursuit of the other.

lllwvlvwlll commented 1 year ago

I don't want to drive this discussion further off-topic, but the mamba VM (blink) was designed to be compiled for language agnostic use for every node implementation and is currently in parity with the reference architecture. It has been in development for nearly a long as the core C# implementation and is performant.

This architecture decision was made after many years developing and maintaining VM solutions in multiple languages and understanding the technical debt incurred as a result. To this day, I consider the decision not to adopt a common core implementation to be one of the largest architectural issues of our ecosystem which could have been avoided.

The value proposition of having multiple implementations of the VM is trivial compared to the bandwidth to maintain them all. This skillset is quite specialized so by taking this approach, we have chosen to utilize some of our most valuable engineering resources who could be working on other initiatives (like collaborating directly on a single optimal solution).

Based on this position, I tend to agree with the idea of using a single core implementation which can be wrapped for use in many areas. I think it's also important to clarify that in the case of this specific proposal, we are talking about a project which will have an extremely low compute overhead. In nearly all practical use cases, the performance improvement of a completely native rewrite is going to be insignificant in comparison to the response latency of relaying a transaction to the node.

Another consideration: In my example above, theBlink VM was specifically designed for packaging as a language agnostic tool. As far as I am aware, all of the SDKs in the ecosystem were not implemented with this requirement as a high priority so I cant provide any comment on how practical this approach would be for the SDK.

crisogray commented 1 year ago

Thank you all for all of the input, this discussion has been very valuable and far more intense than I would have imagined. That being said, I think we are at a bit of an impasse…

In my view we have three options:

  1. Cancel the proposal entirely
  2. Attempt to fund the current proposal as is
  3. Reach a middle ground and potentially submit a new proposal

I think the first option would be a real shame as I think there is real value, and support for, the sort of native Swift developer tools that this proposal would introduce.

The second option would also be a shame in my opinion. I don’t think going against the volume of reasonable critique and opposition, if it were even possible, would result in a healthy community outcome.

I believe the third option would be the most positive and productive outcome. As I commented 5 days ago, I still think this would offer a best-of-both-worlds situation. I think it makes sense to those that want to see a more unified SDK based on a single core, and also to those that want to see a better development quality for Swift developers. I think that with sufficient documentation, especially in-code annotation, a Swift wrapper for neon-js could provide a developer experience that is almost as good as if it were written solely in Swift. The main point that this doesn’t address is the idea that the addition of a new implementation could be good for decentralisation. However, I think given the smaller number of people that would use a native Swift SDK this is less of an issue. With something like neow3j, Java is incredibly widely used so it makes more sense, whereas Swift is less-so. (@lock9 I’m interested in your thoughts on neow3j vs the unified SDK idea.)

It is the unfortunate situation where I think any direction forward twill be at least somewhat disappointing to either or both sides, but I hope some sort of middle ground and a conclusion could be reached. This debate could easily rage on for weeks with strong points from both sides.

Thank you again for all of the input, I look forward to any responses to these thoughts or any new thoughts.

lock9 commented 1 year ago

Thank you all for all of the input, this discussion has been very valuable and far more intense than I would have imagined. That being said, I think we are at a bit of an impasse…

In my view we have three options:

  1. Cancel the proposal entirely

  2. Attempt to fund the current proposal as is

  3. Reach a middle ground and potentially submit a new proposal

I think the first option would be a real shame as I think there is real value, and support for, the sort of native Swift developer tools that this proposal would introduce.

The second option would also be a shame in my opinion. I don’t think going against the volume of reasonable critique and opposition, if it were even possible, would result in a healthy community outcome.

I believe the third option would be the most positive and productive outcome. As I commented 5 days ago, I still think this would offer a best-of-both-worlds situation. I think it makes sense to those that want to see a more unified SDK based on a single core, and also to those that want to see a better development quality for Swift developers. I think that with sufficient documentation, especially in-code annotation, a Swift wrapper for neon-js could provide a developer experience that is almost as good as if it were written solely in Swift. The main point that this doesn’t address is the idea that the addition of a new implementation could be good for decentralisation. However, I think given the smaller number of people that would use a native Swift SDK this is less of an issue. With something like neow3j, Java is incredibly widely used so it makes more sense, whereas Swift is less-so.

(@lock9 I’m interested in your thoughts on neow3j vs the unified SDK idea.)

It is the unfortunate situation where I think any direction forward twill be at least somewhat disappointing to either or both sides, but I hope some sort of middle ground and a conclusion could be reached. This debate could easily rage on for weeks with strong points from both sides.

Thank you again for all of the input, I look forward to any responses to these thoughts or any new thoughts.

Hi Cris, I agree with you. Add me on Discord so I can help you.

By using a core SDK, we could have more than one implementation. It will allow us to have more option. We could even combine SDKs, using parts from Neow3j and NeonJS.

This:image

Allows us to do this: image

To achieve this: image

Attention to the last item. It shows a native iOS SDK composed by multiple implementations. @EdgeDLT This is related to your decentralization concerns.

I want a middle ground too, I'll propose a solution in the next days.

gsmachado commented 1 year ago

As a DAO Member (on behalf of @AxLabs), my suggestion, is:

What about if @crisogray could collect all the feedback, with the support of @lock9 (and this whole thread), and lead a re-submission of this proposal?

I feel that Neo needs new people coming to our community, embracing our goals/ideals with the help of long-term community members, and thriving altogether.

If that's a reasonable (and viable) option, then I suggest @crisogray, that you:

  1. Withdraw this proposal (using the button only proposals' authors can see, here)
  2. Have a chat with @lock9 (he's ricklock#4529 on the Neo Discord server)
  3. Re-submit this proposal with different scope -- maybe it would be nice if you lead it, assuming you'd like to engage in this project for longer. Don't forget to attach this proposal as a "related proposal" during the process of creating a new proposal again (Item 4, here).
steven1227 commented 1 year ago

As a DAO Member (on behalf of @AxLabs), my suggestion, is:

What about if @crisogray could collect all the feedback, with the support of @lock9 (and this whole thread), and lead a re-submission of this proposal?

I feel that Neo needs new people coming to our community, embracing our goals/ideals with the help of long-term community members, and thriving altogether.

If that's a reasonable (and viable) option, then I suggest @crisogray, that you:

  1. Withdraw this proposal (using the button only proposals' authors can see, here)
  2. Have a chat with @lock9 (he's ricklock#4529 on the Neo Discord server)
  3. Re-submit this proposal with different scope -- maybe it would be nice if you lead it, assuming you'd like to engage in this project for longer. Don't forget to attach this proposal as a "related proposal" during the process of creating a new proposal again (Item 4, here).

I agree with this. The purpose of Grantshare is to bring more developers to Neo and contribute to our infrastructure. @crisogray did a lot of research on Neo and he finds the lack of iOS SDK would be a chance for him. I would like to see if there is an improved proposal that covers all the questions above.

lock9 commented 1 year ago

Hi @steven1227 and @gsmachado, not sure if this is the best place to discuss this, however:

We should not expect a developer, even a specialist one, to do proper scoping. Product research not part of the skills of a developer either. How can we expect Cris to come up here and solve a 5-year issue we have in this community? Also, how can we expect him to work alone? Who is reviewing his code? Who is helping him when he has questions? Who is going to ensure that his solution is working? It would be irresponsible and naive of this community to think that a single person will be able to deliver what we need, in the terms of quality.

We need to bring Cris as a human being, not a code machine. Give him the proper attention, and support him with the skills he doesn't have. We need to offer him more than just money. If he doesn't build bonds with the project and other humans, he won't have reasons to stay with us for longer, other than money. It is ok to come here for the money, but it would be better if e stayed for other reasons, and not just money. We need to provide him with mentorship and team-building activities.

If people are here just for money, they will leave for money too. Let's avoid that.

gsmachado commented 1 year ago

We should not expect a developer, even a specialist one, to do proper scoping.

☝️ Agree.

Product research not part of the skills of a developer either.

☝️ Agree. But it can be part.

How can we expect Cris to come up here and solve a 5-year issue we have in this community?

Agree. We can't expect. We have the role to show him the way. The discussion in this proposal/thread was VERY useful! 💯

Also, how can we expect him to work alone?

What I suggest here is that he shouldn't work alone. As I suggested, he can lead the project and get opinions and code reviews from different parts of this community.

Who is reviewing his code? Who is helping him when he has questions?

If comes to me, I will certainly help him by reviewing his code and help him if he has questions. I expect that, if he contacts you, you will certainly also help him, right?

Who is going to ensure that his solution is working?

The peers he asks to review or to exchange ideas.

It would be irresponsible and naive of this community to think that a single person will be able to deliver what we need, in the terms of quality.

It's not a single person. He's not alone. He has all GrantShares #DAO members to contact, a Discord server, Neo Foundation, and many many other devs in the neo ecosystem. There are lots of people that would be willing to give feedback, and make sure to guide him through the process. That's the power of our community.

We need to bring Cris as a human being, not a code machine.

Agree. 👍

Give him the proper attention, and support him with the skills he doesn't have.

We will. I'm confident about it. 👍 💪 💯

We need to offer him more than just money.

Agree, 100%. That's what GrantShares is all about. Or do you think we just give money away? Otherwise, we would not be here discussing. 😄

If he doesn't build bonds with the project and other humans, he won't have reasons to stay with us for longer, other than money.

Again, you're 100% right, it's not about money. It's about ownership and collaboration.

It is ok to come here for the money, but it would be better if e stayed for other reasons, and not just money. We need to provide him with mentorship and team-building activities.

Yes, we are. That's our original plan with GrantShares, and we will be giving our best to follow and make @crisogray comfortable if he feels like doing more things in our community. 💯

If people are here just for money, they will leave for money too. Let's avoid that.

Yes, yes, and yes! Absolutely. My opinion written here doesn't mainly relate to money. Leading a project has more to do with ownership on deciding how the project should be developed, collecting feedback from the community, learning from others, and reaching a middle ground for all of us.

lock9 commented 1 year ago

Hi @crisogray , please don't forget to contact me on Discord.

I've found evidence that a native Swift SDK may be a good idea. The real problem is the lack of a unified interface (core capabilities), scattered documentation, and bad SEO for all our SDKs.

devhawk commented 1 year ago

Sorry I'm late to this discussion

lock9 commented 1 year ago

Hi @devhawk ,

I am 100% in favor of a native iOS SDK. Yes, xplat libraries like neon-js can be used with xplat mobile app stacks like react-native. But I suspect that the % of native iOS apps > % of xplat iOS apps.

My concern is mostly about considering a mobile SDK. We need an SDK for iOS, in Swift. I think we all agree with that. What we can't do, is have an SDK that is different on iOS and Android. This is not how it works in mobile development. People expect compatible SDKs. In our community, react-native is the most used mobile framework. How could they use this SDK if it works completely differently from their Android counterpart? They won't be able to wrap this SDK and will have to continue to use neon-js.

I don't think a native iOS SDK should build on top of another stack. My diagram that @lock reposted in https://github.com/AxLabs/grantshares/issues/18#issuecomment-1217254008 was intended to drive consistency across SDKs - using the same basic types for shared concepts like blocks and transactions regardless if you're building a contract, a dApp or a full node. It's not intended to imply a single implementation of shared concepts for a given platform. AFAIK, we don't do that on other platforms / languages.

The 'types' are a problem on all SDKs. Sometimes we use strings, sometimes it's a hex string, sometimes it's Base64. What if one SDK works with hex and the other with base64? Developers will cry in despair. It's also not recommended that we write our own crypto functions, so we should try to reuse some of that too. It's important to notice that using other libraries doesn't mean the SDK won't be native.

I spoke to Ben already, he is considering other libraries to use, such as the swift-crypto and other native libraries.

I don't keep up with iOS development, so I'm not sure what the breakdown is between Obj-C and Swift for modern iOS app development. What's the interop story between Obj-C and Swift? Can Obj-C developers use libraries built in Swift? I would think a "native iOS SDK" would have to support Obj-C and Swift, but if modern iOS developers have ditched Obj-C en masse and switched to Swift, maybe my thinking is outdated.

They are fully interoperable, we should use Swift, it's newer and has more adoption.

How much additional effort would there be to support Obj-C / Swift macOS development with this SDK?

Crypto-swift is compatible with macOS, AppleTV, and watchOS, so I think we should be fine. Not sure if we will need other dependencies.

ediopia commented 1 year ago

It is interesting to see all the comments on this proposal. I am not a DAO member but I want to ask OP and Grantshares members as a NEO dApp developer.

How are you going to maintain this SDK up-to-date after work is done if there is changes in the future? Will there be any support? I am worrying because I've seen some unmaintained tools since the legacy time and it has caused some troubles for dApps.

crisogray commented 1 year ago

Hi all,

Thanks for the continued interest.

Apologies for my delay in getting back, I've been busy over the last couple of weeks creating an updated proposal that I hope to submit in the next couple of days.

The main idea of the adapted proposal is to create an SDK in native Swift but in a manner that contributes to a consistent interface between existing SDKs. With this in mind, the current plan is to replicate the public interface of neow3j in Swift. This way, although running on different platforms, developers would have an entirely familiar experience between the two SDKs. Not only this, but this would remove a large design component of the project, as much of it is already laid out, making the proposal smaller in scope overall. It means that documentation could also potentially be shared between the two with minimal adaptation.

I'd be interested in opinions on this idea.

Thanks again to all of you.

@ediopia In response to your query about ongoing support. I intend to support the SDK voluntarily going forward for any issues and minor changes. In the event of a large-scale upgrade I may seek support depending on the work involved. If I were to move in the direction of replicating the interface of neow3j, I would also be somewhat dependent on their updates, which is another potential concern but one that I think is not necessarily the end of the world.

devhawk commented 1 year ago

I think we all agree with that. What we can't do, is have an SDK that is different on iOS and Android. This is not how it works in mobile development. People expect compatible SDKs. In our community, react-native is the most used mobile framework. How could they use this SDK if it works completely differently from their Android counterpart? They won't be able to wrap this SDK and will have to continue to use neon-js.

Based on my experience, this is not accurate @lock9. Things need to be similar - terms like block, transaction and wallet need to be used similarly across different languages. But generally speaking I don't think developers expect things to be the same across languages and platforms. For example, every language has slight variations on async remote operations. But Java and Swift don't have "compatible" ways of doing async.

crisogray commented 1 year ago

Based on my experience, this is not accurate @lock9. Things need to be similar - terms like block, transaction and wallet need to be used similarly across different languages. But generally speaking I don't think developers expect things to be the same across languages and platforms. For example, every language has slight variations on async remote operations. But Java and Swift don't have "compatible" ways of doing async.

I think that the similarity you mentioned is what I'm aiming for in the updated proposal. I want the SDK to be familiar to anyone that has used neow3j but will adopt the Swift-like features under the hood where appropriate.

I'm am going to release the updated proposal imminently so will be closing this issue, but would very much like for discussion around the new proposal and the idea in general to continue on the new thread

Thanks all again

grantshares-dapp[bot] commented 1 year ago

🚫 This proposal was cancelled (closed discussion) on request of the proposal's owner.

igormcoelho commented 1 year ago

I have been contacted recently for developers interested in iOS SDK, and the current one is really old... I think this is a nice initiative in the spirit of Neo, having developers developing on the native ecosystems. I guess pricing and strategy can be adjusted, to be more feasible, but I would surely support the direction of such initiative.

crisogray commented 1 year ago

@igormcoelho Thank you for the support Igor!

For all interested, there's now an updated proposal at this link.

Please take a look and let me know what you think!

Thanks