OperationFabulous and 1400 BTC Bounty by NoAgendaMarket

[BioMike]

For the ad upload I currently don't accept images not larger than 100KB. Is this sufficient for most people?

I suggest to make it smaller, e.g. 40kB. An ad is going to be served thousands of times each day. It's worth a little effort to make the ad load fast.

I'm not saying this for the sake "of the internet"; I'm saying it for the sake of the service. Owners of websites don't like ad services that make their website seem slow.

True, that was also, partially, my point. But I have no reference of what is a reasonable size. That's why I'm asking.

[1713970665]

1713970665

[1713970665]

1713970665

[1713970665]

1713970665

[1713970665]

1713970665

[1713970665]

1713970665

[1713970665]

1713970665

[Anonymous]

For the ad upload I currently don't accept images not larger than 100KB. Is this sufficient for most people?

I suggest to make it smaller, e.g. 40kB. An ad is going to be served thousands of times each day. It's worth a little effort to make the ad load fast.

I'm not saying this for the sake "of the internet"; I'm saying it for the sake of the service. Owners of websites don't like ad services that make their website seem slow.

True, that was also, partially, my point. But I have no reference of what is a reasonable size. That's why I'm asking.

40kb sounds about right.

[BioMike]

Ok, I'll change it to 40Kb.

Here is a new update:

Placing bids works and optimal bid is determined (highest bid to win from 2nd highest). The advertiser can see all of his/her bids, but not if he/she is the highest (or the other bids on the same site). The publisher doesn't know anything about the bids on his site yet. This is something that I still have to work on.

This morning I worked on a AJAX script to load the data for the publisher and to put on his site. Because I have 0 experience with JavaScript/AJAX I'm already happy to have something that works like I want. This script is very static, so also here a lot of room for improvement.

[kiba]

How close are you to a proof-of-concept.

[BioMike]

A proof-of-concept should not be far away any more. Just to show in a test environment.
I need however to make one script to allow bidding on the test sites that are entered while testing.
And some things will have to be deactivated, because they aren't functional yet.
I might even set up a test website with a functional ad box to show the results of the bidding.
I'll see if I can put something in place tomorrow, then we could do some testing after that.

Please note that the layout of the site is ugly, I've already been thinking about a better layout.

Update for now:

Bids are now viewable for the publisher on a detail page for the site that the ad is on. The owner
of the site has also the possibility to delete bids that he/she doesn't want on his/her site.
(Spend a lot of time to get some javascript code in shape to show the ad).

[BioMike]

Didn't make it for the proof-of-concept. While setting it up I noticed that some things didn't work like I wanted.

Did today:
- Fixed an issue with session stealing cookies (publisher could hop over to the advertiser site and have access to some users account, although in a production setting both sites would run on different spots, so that would not happen, valuable lesson anyway).
- Hacked up a quick script to approve websites, so that they have setup everything correct before advertisers can bid on the site.
- And (this took me long) Ajax doesn't allow cross-site scripting, doh. So I looked at how project wonderful handles this, and now I have something that works between different sites. Just needs to make it a bit more flexible (now it just dumps a static file).

I'll shift the proof-of-concept a few days back (over the weekend?).

[BioMike]

Did some minor fixes/improvements yesterday evening (you can't bid with the same ad on the same site again and ads respect the ad_type of the site now when placing bids).

I have now everything in place for a test run today, PM me if you are interested in a link to the test sites and a demo running on a other domain.

[kiba]

* kiba panics because he doesn't have a site to use it on.

[BioMike]

* kiba panics because he doesn't have a site to use it on.

No need for hurry. It will take a bit more time to go live. But my todo list is getting shorter.

What I did today:
- Redesigned overall layout of the site. Now I have more space to put things down and it looks better.
- Details about bids on a site for people who did a bid on a site (site details and see what other bids are placed on that site). Still needs to be made a bit nicer.
- Deleting a bid is now possible for advertisers.

[BioMike]

Update:

- CSS Fixes that didn't show up in my FF3.5, but that I later saw in FF4.0b and IE8.0.
- Keywords for publishers are now in. First 5 keywords per site are free, after that 1btc per month per keyword (if you put a keyword in halfway the month, it counts the remaining days and calculates the amount for the remaining days for that month).
- Website detail page for publisher cleaned up a little so it looks better.

[BioMike]

Not much of an update this time.

I'll be heading to my parents for Christmas this afternoon, so don't expect to be happening much next few days.
The thing that needs to be done now is the financial accounting for both the publishers and advertisers within the site.
I've run some tests yesterday on my test system and I was slightly disappointed with the speed:

System at 535MHz takes about 128 seconds for 15000 updates to the database.
System at 1.20GHz takes about 74 seconds for 15000 updates to the database.

(Project wonderful has about 7600 sites that it hosts ads for, so the 15000 updates is I think a sane value for a PW size of site.)

Memory doesn't seem to be an issue (taking up only ~15 - 20 MB during the updates for the whole process).
Disc IO was not a bottleneck in this test, but might become a problem on a live system.

The database that I will be using will also be doing other queries and is larger than this test database,
so actual updating of the accounting fields will be slower. On the other side, the host running the site will
be much faster than the 1.20Ghz and I will be able to implement some tricks to make things faster and less
stressful for the database.

[russ]

I'm also working on a publisher / advertising system backed by bitcoin.

Is the requirement for the bounty for it to be opensourced?

[kiba]

I'm also working on a publisher / advertising system backed by bitcoin.

Is the requirement for the bounty for it to be opensourced?

I don't think so, as noagendamarket never objects.

You will have to ask noagendamarket how the bounty awarding process work when there's competition.

[Anonymous]

I'm also working on a publisher / advertising system backed by bitcoin.

Is the requirement for the bounty for it to be opensourced?

I don't think so, as noagendamarket never objects.

You will have to ask noagendamarket how the bounty awarding process work when there's competition.

Perhaps instead of jumping into development half cocked people should actually be sure what the aim of the bounty is . While I dont have a problem with projects being closed source - see mt gox et al , I prefer open source as the developer cant hold the community hostage through abandoning the project and/or inserting malicious code that harms people using it or leaving us hostage to the whims of one person. Im not a developer so I cant examine code to ensure it is doing what it claims. I need to rely instead on the members of this community who I know and trust will ensure nothing bad gets through and who can oversee and improve the product.

As such if this clearing house isnt the same open source license as bitcoin it wont qualify. The whole bitcoin community should benefit from this not just one person.  

Im not paying an open source bounty for closed source code.  I may as well give money to project wonderful if that's the case.


The one who has workable code on github (and verified to be acceptable) for a bitcoin project wonderful combo will claim the bounty.

[BioMike]

Perhaps instead of jumping into development half cocked people should actually be sure what the aim of the bounty is . While I dont have a problem with projects being closed source - see mt gox et al , I prefer open source as the developer cant hold the community hostage through abandoning the project and/or inserting malicious code that harms people using it or leaving us hostage to the whims of one person. Im not a developer so I cant examine code to ensure it is doing what it claims. I need to rely instead on the members of this community who I know and trust will ensure nothing bad gets through and who can oversee and improve the product.

As such if this clearing house isnt the same open source license as bitcoin it wont qualify. The whole bitcoin community should benefit from this not just one person.  

Im not paying an open source bounty for closed source code.  I may as well give money to project wonderful if that's the case.

The one who has workable code on github (and verified to be acceptable) for a bitcoin project wonderful combo will claim the bounty.

Fair... (although "the same open source license as bitcoin" might not be ideal, AGPL might be better suited for web-based service code).

However... I won't be open sourcing any code before having it up and running and people using the service consider it as something they trust using. Releasing the code too early might cause other people jump on it and set up "half-backed ad services" based on the code (quick and easy money), causing users to be unsatisfied by the service (slow servers, (introduced) bugs, suddenly disappearing ad services, etc). This would not be good for the bitcoin community. I spend some considerable time and effort in it, so I also want to finish it in a controlled situation.

<edit>
Update:
A small change in the algorithm of the updates to the database had a huge impact:
System at 1.20GHz takes about 24 seconds for 30000 updates to the database. (Less than half the time for 2 times as much updates!!!)

I've been coding a part that I call "Jeeves". He will be the one that will be doing the updates (cleans up old and expired bids, takes care
of the payments and sends the money to the publishers). Jeeves will be running as a daemon (initially as a cron job).
</edit>

[Anonymous]

Perhaps instead of jumping into development half cocked people should actually be sure what the aim of the bounty is . While I dont have a problem with projects being closed source - see mt gox et al , I prefer open source as the developer cant hold the community hostage through abandoning the project and/or inserting malicious code that harms people using it or leaving us hostage to the whims of one person. Im not a developer so I cant examine code to ensure it is doing what it claims. I need to rely instead on the members of this community who I know and trust will ensure nothing bad gets through and who can oversee and improve the product.

As such if this clearing house isnt the same open source license as bitcoin it wont qualify. The whole bitcoin community should benefit from this not just one person.  

Im not paying an open source bounty for closed source code.  I may as well give money to project wonderful if that's the case.

The one who has workable code on github (and verified to be acceptable) for a bitcoin project wonderful combo will claim the bounty.

Fair... (although "the same open source license as bitcoin" might not be ideal, AGPL might be better suited for web-based service code).

However... I won't be open sourcing any code before having it up and running and people using the service consider it as something they trust using. Releasing the code too early might cause other people jump on it and set up "half-backed ad services" based on the code (quick and easy money), causing users to be unsatisfied by the service (slow servers, (introduced) bugs, suddenly disappearing ad services, etc). This would not be good for the bitcoin community. I spend some considerable time and effort in it, so I also want to finish it in a controlled situation.

<edit>
Update:
A small change in the algorithm of the updates to the database had a huge impact:
System at 1.20GHz takes about 24 seconds for 30000 updates to the database. (Less than half the time for 2 times as much updates!!!)

I've been coding a part that I call "Jeeves". He will be the one that will be doing the updates (cleans up old and expired bids, takes care
of the payments and sends the money to the publishers). Jeeves will be running as a daemon (initially as a cron job).
</edit>

Whats wrong with the license bitcoin uses? It seems to be working well so far.   

[BioMike]

Whats wrong with the license bitcoin uses? It seems to be working well so far.   

By installing the code you're not distributing it, but only using it. This causes the copyleft provisions not to be triggered.
But on the other side, MIT (that bitcoin uses) isn't subjected to copyleft also.

If you want to keep changes and extensions (derived work) to the released code also open, you don't want to go with MIT.

And of course, saying this will trigger the whole GPL vs BSD discussion again.

[kiba]

Progress report?

[BioMike]

Progress report?

Sorry for the slow reply. I've been at the parents-in-law for new year.

Mainly a lot of coding on the background, some refactoring, and expansion of the ad delivery code. Have been doing some testing of the current system (internal payment and switching of ads when one finishes its bitcoins), but some of the new code still has to be tested. Some loose ends still have to be tied together.

[kiba]

Progress report?