We are building a Solana based application which will mint Semi-Fungible tokens (for Fungible Assets) let people trade them.
What we want next is to add metadata to this mint through which we are also going to set the creators and the seller fee basis points for royalty payments. We know how to do this and we have done it.
Anyway, the problem is the following: all the docs available on Metaplex we’ve seen are revolving around NFTs, Master Editions, Printing Editions, Auctions, etc. - which is not the case for us as we need to mint more than one token from the same mint.
The most important thing is to manage to benefit from the royalty fees each time shares are being traded on the secondary market. So we don't need auctions, vaults or other mechanisms like these.
Initially, we were thinking about Serum, but we don’t know whether
Serum also takes care of transferring the royalty fee to the
creators when the funds are settled.
After Serum, we’ve looked at the examples in the Metaplex
documentation about Metaplex Storefronts, but, as I said above, that
was really focusing on NFTs, Master Editions, Printing Editions,
Auctions, etc. - which don’t seem to fit our use case of Fungible
Asset. Maybe can this be customized for our Fungible Assets use case
somehow?
Would you be so kind to help us clear up a little bit what approach is the best for our use case and our needs?
Serum v4 (not released on mainnet yet) does support Metaplex royalties (see this commit). It should be released on mainnet in the coming weeks/month.
I am not aware of any other smart contract on Solana which supports this feature. However, you could probably create your own fork of an open source AMM and add a logic similar to the commit above.
Related
More than a question this is going to be a long story and a call for all those professionals, developers and merchants that are actively using paypal adaptive payments (preapprovals and chained).
I (and my team with me) strongly think that adaptive payments are and have been a great solution.
Since we adopted them in late 2012 we immediately understood the potential and the flexibility of this great set of APIs. The adoption of this APIs in Italy was something like a nightmare in those times. No docs in italian, no support in italian, everything was done in english with one great support person of paypal in Dublin following us in the integration at the phone :) We were pioneers in our country but at the end we finally had our flows done.
Preapprovals + chained payments and the world can be in your hand.
We could do almost anything and this was what we did. A great platform for buying groups that in those last year is expoloding in our country. Today we have dozens of active and happy users (thousands we brought to paypal) and almost one houndred very selected merchants that we've followed step by step with the paypal team in the limit removal nightmare stuff. One, by one.
And here comes the call.
How many are we using them and what will be the future and possible migration solutions?
As almost all of the users of adaptives knows those APIs are well functioning but deprecated since few years. This means that nobody can start new integrations with them but, worst of all, that all those that are actively using them - like us - still don't really know what the future will be. I'm fairly certain that we can't be alone. I'm almost sure that there are other businesses, merchants, developers who have built great ideas relying on those APIs and now that we've given soul and blood for years putting all of our efforts in developing, optimizing, updating and growing our platforms and our communities, we're at a crossroad: to wait and hope or to look for alternatives.
On an app owner view, there's no understandable reason why paypal should shut off those APIs and, infact, till today, fortunately we've heard nothing about a sunsetting of those APIs, however we all know that they have been deprecated and any of us can safely say that there won't be a sunsetting or a forced migration in the future.
So, why don't we start joining our voices to have clear, understandable and certified roadmap and / or plans around this topic?
Talking with the commercial team in Dublin, they say that everything is ok with adaptives and they will continue working for a long time (and this would be great) but, on the other side, talking with the MTS team the view is a little bit different and no so enthusiastic go on mood in the air. Most of all because of the introduction of the PSD2 Directive in Europe.
As many in the European market should have heard, in the last few months another big concern (investing everything in the payments industry) is the PSD2 compliance and maybe just for this directive that the future of adaptives could be involved too.
Adaptives unfortunately are not PSD2 ready and the hope that paypal will put efforts in making them compatible while it is a deprecated solution is very thin.
The strong customer authentication, mandatory in the new rules schema would force the tech team to update all their products but, always on the merchant / app owner / user view, it seems more plausible that paypal will put the more efforts in the new products instead of renewing the old ones.
However, adaptives are both:
a great solution used by a lot of merchants (again, how much we are?!) in the world continuatively draining new users and merchants (for free) to paypal (just for how the adaptives and preapprovals works, in many cases you're forced to open a paypal account and all we app owners have done this for years);
an easily adjustable tool to be PSD2 ready
We're now in a "grace period" for PSD2 and that to make Adaptive payments complying with PSD2 directive wouldn't be so hard: preapprovals are the CORE and if you add a strong customer authentication to the preapproval flow the great part of the job is done. Chained payments made direclty at the presence of the user too, just adding a strong customer authentication should fit the needs and server to server chained payments sould fall in the MIT (merchant initiated payments) that seems to be out of the object of the directive.
Forcing migrations, on the other hand, would result in loosing a lot of customers, merchants, app owners that for some reason can't change the architecture because of the specific business model or because they don't find real concrete solutions in alternative APIs. Fixing it appears to be a better solution.
The call to all the adaptive payments users is to join this conversation and bring your thoughts, just to see if we're alone or if we're a lot with the same issue at the door.
An enthusiastic and happy adaptive heavy user and owner in Italy.
Cheers, Fil
In planning for the future, the best approach would likely be to put together a list of your platform's requirements and expected volume, and contact PayPal regarding: https://developer.paypal.com/docs/commerce-platform/
You can also look at other options
I don't think anyone knows exactly how long Adaptive Payments will remain available as a legacy service for existing integrations, but I would expect it will be long enough for you to set up a new one that users can migrate to
Normally all our upgrades, feature or bug-fix, are incremental. This seems obvious because even to develop a bug-fix we take the latest code-base of our product. However, this leads to a requirement that our customers have to update the software to the latest version even to get a bug-fix, they get the features as well as bug-fixes.
Recently, customers are telling us that they want the ability to get bug-fix patches without having to use new feature enhancements. Basically they want the bug to be fixed but they don't want new features. This is a dilemma for us. This is possible if the bug-fix changes a different set of binaries than the features. However, many times the features and bug-fixes are in the same binaries.
Is it even possible to create an upgrade that can be applied on any software version independently? Do others do this? Are Microsoft or Office KB patches ever non-incremental? Any guidance or links to relevant articles are highly appreciated. Thank you.
What the customer wants is normal but that does not mean that this is an easy problem.
What you describe is at the heart of configuration management. SCM is not just using a tool like git, it is using such a tool to solve the needs present. There is no silver bullet, to meet configuration requests take a lot of work and preparation of your code. I see that you have not tagged this as configuration management; this is exactly what you need to research if you have not.
Back to your specific request: The customer wants to be able to release bug fixes without the features you are continually working on. For the purposes of this answer I will assume your business model is that you offer a product which is a living thing and that several customers 'subscribe' to.
Branching strategy based on customer
Customer X, Y, and Z all gets different branches. Along with a developing branch from which you can pull features/bug fixes to the customers that want them.
This solution I would say is often very challenging (SCM generally is), you have to deal with diverging codebases and the developers have to be very aware of your work-flow.
Release branches
Having a branch for every released version which you can patch with bug fixes while not bringing in the new features is what I suggest. You're question is a bit unclear what you mean by incremental, if this somehow refer to the distribution of the patches itself then that is another matter and this answer will be less useful.
Feature-flags
You deliver new features to the customer which do not want them but they are hidden behind logic in your application. This can be hard to combine with what you describe as 'complete revamp'. This can also have other advantages as it makes it easy to perform A-B testing.
It places requirements on your architecture and also discipline when it comes to what to allow, too many feature flags for every little thing and it can get un-maintainable.
Have a strategy
You need to plan for this or you can not satisfy your customers needs. And it may be very well that if you have customers who wants the wrong things you have to negotiate. But providing bug-fixes without new features I think is the minimum
The books I read on this is old, but here is one i remember anyway: Wayne A Babich: Software Configuration Management - Coordination for Team Productivity
Release Strategies on the Rene Moser blog may be helpful.
The LTS (Long Time Supported Versions) section seems applicable to your concerns.
Regarding your questions:
Is it even possible to create an upgrade that can be applied on any
software version independently? - Sure, but it takes extra time, effort and money (usually).
Do others do this? - Yes.
Are Microsoft or Office KB patches ever non-incremental? - Yes, for major releases; but not KB patches.
A follow up question: is it worthwhile to do the extra work to facilitate non-incremental software releases for your software users?
The answer to this questions depends on your customer base, which may require a long meeting with the software developers and those in Marketing. If the customers wanting non-incremental releases are significant in terms of their numbers and revenue, then the extra work is probably necessary to keep those customers.
I'm searching for a shopping cart or web store framework that supports multiple vendors.
There are many, many shopping cart frameworks out there: that page lists couple of hundred. In spite of the comparisons on that page, supporting multiple vendors isn't a comparison item, probably because it's a rare requirement. Separate to that page I have evaluated a few of what appear to be the top frameworks, and none that I evaluated supported this feature. Which carts would you recommend?
Commercial is okay, although I would prefer open source.
Platform (Windows, Linux, ASP.Net, PHP, Ruby... Minix, Fortran... :)) doesn't matter.
A system
where I manually add vendors who request it (instead of them freely
being able to sign up) is also okay, if there's a store where that's
possible but freely joining up isn't built in yet.
Rationale: I'd like to create an app-store like website. "App store" is a close analogy: it won't sell apps, but it will sell digital goods and I'd like anyone to be able to sell their item on the store. It's this second requirement, multiple vendors selling through the store, that I'm finding hard to satisfy.
I've used multiple shopping cart frameworks (a lot of them broken), and my favorite (which just so happens to support multiple vendors) is PrestaShop. It's free, open source, and suppports all that you asked for. Is this the framework you were looking for?
-JXP
The Wikipedia page you cited lists multiple vendor support as a column in Other Features, along with features that are pertinent to your search.
This question otherwise requires domain knowledge and likely requires multiple answers. The best I can do is offer the bounded set of software that competes directly within this space, at least according to Wikipedia.
The easiest solution for achieving your stated goal of allowing multiple people to sell on your site while exercising fine-grained control of who can and cannot do so is perhaps using WPMU's MarketPress in tandem with BuddyPress or WordPress Multisite. I'm not a die-hard fan of WordPress, per se, but that might be an expedient way for you to get to a minimal viable product and to validate your idea before shelling out the time and/or cash to custom build it from the ground up, and/or labor ad nauseam with tweaking an existing framework. MarketPress is a good plug-in that'll give you many of the features of a full-fledged e-commerce framework... BuddyPress, of course, will allow you to set up individual vendor's with their own sites under your brand. The two work together. More on MarketPress at:
http://premium.wpmudev.org/project/e-commerce/installation/
Another alternative is Jimdo's PagePartners. I haven't used it, but it looks intriguing. I like their design sensibilities, and their stated business ethos. This might be a viable option, too. The caveat being: it's not white label. More info about Jimdo's PagePartners here:
http://www.jimdo.com/pagepartner/faq/
Finally, another interesting CMS to explore is SetSeed. I think it'll allow you to launch multiple sites for each vendor via a central hub you control, and will allow you to maintain your branding within each. How, the,n any sort of renumeration would flow back to you for setting up an individual vendor's store would be up to you to figure out... This is a fairly new CMS and it looks like it's evolving smartly and rapidly. If you require some customization of it, to approach more specifically what you ask for, now might be a good time to reach out to the developer...but you might be able to think of an effective way to adapt it for your use right out of the box.
http://setseed.com/multi-site-cms/setseed-hub/
Unfortunately, none of the above is open-source--but, again, the ease by which you could get to a functional site approximating your idea may off-set that drawback. Jimdo is an open-source contributor, however. So, maybe even an e-mail to them might be a fruitful dialogue to begin. If anything, check out each of the above, and it may influence how you search for other solutions, and will at least provide some models in your own thinking or with other developers. The shopping cart is an integrated feature, I believe, in all of the above cases. With regard to giving your vendors the capacity to deliver digital goods (e-books, mp3s, etc.), check out Fetchapp.com. Very cool app. Very easy to set-up...could probably be rolled into one of the above frameworks. The frameworks would handle the issue of individual vendor profiles and/or sub-domains.
I have a website where people do simple cognitive psychology experiments. Currently, people volunteer. To increase numbers of responses, I would like to offer micropayments in a manner similar to Mechanical Turk*.
My question is, What would would be the best system to use to make these payments? I would guess that both paypal and flattr would be options. Has anyone with experience with setting up a micropayment system like this be able to offer advice?
cheers,
Mark
*I am not thinking about using mechanical turk itself, just because I do not think I would be able to control the web based studies exactly I would need.
Flattr would work in your scenario:
Each person doing the test would need a Flattr account.
They’d need to login with their Flattr account on your site (like on fundd.de) or connect your site with their Flattr (easy with OAuth).
Once they’ve taken the test you manually Flattr them and by controlling your monthly budget you control how much each click is worth.
Our API makes setting this up fairly easy and straightforward http://developers.flattr.net/
Downsides:
Required to sign up with an additional service.
Flattr currently caps monthly spending at €100 so if you have lots and lots of testers you’d run into problems of making the payment high enough. We are reconsidering this, at least for users in good standing.
Monetary incentives for testers bring in a different crowd and can influence the results of their tests but you probably already know that.
Cheers,
Teller
PS. I work at Flattr.
I've done quite a bit of searching for a CMS platform or robust framework that will perhaps facilitate the management of signup and subscriptions right of the box with a Twilio tie in.
Thus far I've only been successful at finding how many startups have been funded by the Twilio fund, who's building the nextgen voice enabled app, and various other things of that nature vs any real meat. Seems that there's a dearth of meaningful information without applying a plethora of negative google filters to reduce matches and even then it's still not giving anything real meaningful wrt my search.
So, I'm hoping that someone may have a better eye on the lay of the Twilio landscape as far as already existent systems go that can handle the bulk of needs that exist for a "regular" CMS esque site that needs to also handle subscriptions and e-commerce related tasks.
Hitherto I've just planned to build something out myself, but I wanted to do a sanity check before I spend a lot of time that could perhaps be obviated.
My suggestion would be to find a CMS that does everything you want (except the twilio links), on the platform you want, and then just add the Twilio stuff in. Twilio is simple to use, and should be simple to add-on to most open source CMS's. It'll probably be the easiest part of the project....