Open imwatsi opened 4 years ago
This is excellent.. thanks for starting the discussion.
A native post is structured just like an ordinary post in a community. The difference is that it is marked "sponsored" and it declines payout.
I like this idea.
Interactive polls give community members a chance to share their opinions on a certain topic/question as well as see what other community members think. These will differ from the normal polls that members can make in that they will be displayed on sections set aside for such polls, will be marked "sponsored" and will decline payout.
Are you suggesting hivemind implement polling or would this be handled via different service? What usage of sponsored polls do you envision?
Ads that don't get approved by moderation or that are cancelled by the creator should trigger a refund
Refunds are tricky on-chain, it may have to either work on trust, or use escrow.
And an idea I've been mulling over: promoted post could be a single top slot; the promoted post shown is picked at random among all current promoted posts, with the probability of being chosen proportional to promote cost. E.g. if there are two promoted posts, one for $10 and one for $90, the first would be shown on 10% of views.
Awesome. I'm glad you like the ideas.
Oops, fat finger mistake.
Overnight, I had time to think and the vision is getting clearer. I will write a comment to add more meat to the ideas.
I totally agree with the refund issue, it might have to be trust or escrow (as some do it now).
Your idea blew my mind. It's a neat gamification of the legacy promotion feature. The two options can offer different forms of exposure. Wow. I'll be mulling over that idea myself for a while.
I compiled this from my notes (it's quite long):
Okay, so the approach I have in mind uses a combination of JSON Metadata (posts) and Custom JSON operations.
e.g.
New operations: ad_submit
, ad_approve
, ad_revise
, ad_reject
JSON Metadata:
{
"community" : "example_community",
"ad_type": "native_ad",
"ad_properties" : {"devices: "mobile_only"}
}
Or....
{
"community" : "example_community",
"ad_type": "slideshow",
"ad_properties" : {
"total_slides" : 3,
"slide_links" : ["https://...jpeg", "https://...jpeg", "https://...jpeg"],
"time_delay" : 5,
"devices" : "all"
}
}
So we only publish syntax/guidelines/technical documentation that devs should follow for compatibility with hivemind, but it's still flexible enough to add more ad types. Front-ends will access to this JSON data from DB so they can parse and display.
Another important aspect is that it will use a time based approach, where JSON Metadata (post) would be:
{
"community" : "example_community",
"ad_type": "native_ad",
"ad_properties" : {
...
...
"start_date" : "1970-01-01T00:00:00"
"end_date" : "1970-01-01T00:30:00"
"duration" : 30 # minutes
}
}
From a time-based approach you get:
1):
price_per_unit
= total_bids/total_minutes`total_bids
because you can send more tokens to push your ad higher up review queue (more on this in 2) below)Since each ad will have a price per unit:
2):
The above enables the creation of two front-ends:
Another emergent benefit is that it will be easy for someone to check if an ad is being displayed in a community, at the set time and throughout purchased time span. It also makes planning for time sensitive ads possible.
DB will need a table for ads, with aggregated info like price per unit time and dates, and ad status. I'm still working out kinks in logic before writing any code.
Other ideas I'm working on include data integrity checks to avoid exceptions, checks and balances, and expanding data states seen by front-end developers.
What's the ad_revise
op? Might it be better for admins to reject an ad, then have the creator submit a new one?
Yes, that's a good point. Admin can issue ad_reject
and advise a revision in notes.
Creator can then edit the post and issue another ad_submit
op.
P.S. About your question on polls: I will work on a way to have polls as post types used in communities, so the same type can be leveraged for ads. Were you already working on a polls implementation?
Also, to avoid the refund issue, we can use ad_bid
op for creators, so that ad space and time is allocated only after a valid payment (giving creator time to verify go-ahead). Bids can be changed/cancelled at will, leaving refunds only for rare cases like downtime. It'll be more of a customer service issue.
I'm updating the specs doc and dev_scope as I work, so you can get more details there.
Hi @roadscape
Could you help me get access to the communities beta? I would like to discuss Native Ads with the dev community. You can send credentials to imwatsi@outlook.com
Hi @roadscape,
I recently started investigating if a native ad system could be added to hivemind in a future update with minimal changes to core codebase.
This would augment the "promoted" post feature, giving developers more options and flexibility. For those who don't want to have a promoted section, but prefer more integrated/varied means to offer ad space.
I forked this repo and began working on
/docs/native_ads/
to develop more detailed specs. It is still in pre-alpha and I was hoping to get your feedback.The links are below:
Native Ad System - Overview: https://github.com/imwatsi/hivemind/blob/master/docs/native_ads/native_ads.md
Development Scope: https://github.com/imwatsi/hivemind/blob/master/docs/native_ads/dev_scope.md
Idea origination: https://steemit.com/communities/@imwatsi/what-about-steem-s-utility-value-as-an-attention-token